Hi, I'm back again :P
Since it's probably about time for it, and I forgot to send that email a while back, I might as well ask now: are there plans to make Wine use libdecor at some point in the future, so that there are "native" window decorations for desktops that don't provide xdg-decoration? A lot of the work here for compositor-initiated window closing is a requirement for that.
There may be performance implications for this, IIRC, since you'd have to work with another library's event loop on top of another GUI toolkit not made for games, and GTK doesn't support wl_subsurfaces normally *iirc*. SDL does it, at least, so there's that. But something to maybe consider. I'm satisfied with the default window decorations right now, myself.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3909#note_46062
> ```diff
> +static uint32_t spirv_compiler_emit_load_ssa_reg(struct spirv_compiler *compiler,
> + const struct vkd3d_shader_register *reg, enum vkd3d_shader_component_type component_type,
> + unsigned int swizzle, unsigned int write_mask)
> +{
> + uint32_t val_id = spirv_compiler_get_ssa_register_id(compiler, reg);
> + assert(val_id);
> + return val_id;
> +}
> ```
This doesn't emit anything, and "component_type", "swizzle", and "write_mask" are unused. More generally, it seems the only caller could just call spirv_compiler_get_ssa_register_id() instead.
> ```diff
> @@ -3912,6 +3938,13 @@ static void spirv_compiler_emit_store_reg(struct spirv_compiler *compiler,
>
> assert(!register_is_constant_or_undef(reg));
>
> + if (reg->type == VKD3DSPR_SSA)
> + {
> + assert(reg->idx[0].offset < compiler->ssa_register_count);
> + compiler->ssa_register_ids[reg->idx[0].offset] = val_id;
> + return;
> + }
> +
> ```
Here we seem to go entirely the other way, and simply inline the counterpart to spirv_compiler_get_ssa_register_id(). I.e., why do we have spirv_compiler_get_ssa_register_id() but not spirv_compiler_set_ssa_register_id()?
> ```diff
> +static void spirv_compiler_emit_ssas(struct spirv_compiler *compiler, unsigned int count)
> +{
> + assert(!compiler->ssa_register_ids);
> + if (!(compiler->ssa_register_ids = vkd3d_calloc(count, sizeof(*compiler->ssa_register_ids))))
> + {
> + ERR("Failed to allocate SSA register value id array, count %u.\n", count);
> + spirv_compiler_error(compiler, VKD3D_SHADER_ERROR_SPV_OUT_OF_MEMORY,
> + "Failed to allocate SSA register value id array of count %u.", count);
> + }
> + compiler->ssa_register_count = count;
> +}
> ```
This doesn't emit any SPIR-V.
> ```diff
> @@ -523,6 +524,7 @@ enum vkd3d_shader_register_type
> VKD3DSPR_RASTERIZER,
> VKD3DSPR_OUTSTENCILREF,
> VKD3DSPR_UNDEF,
> + VKD3DSPR_SSA,
>
> VKD3DSPR_COUNT,
> ```
This is perhaps subtle, but note that this will cause init_sm4_lookup_tables() to map VKD3DSPR_SSA (like VKD3DSPR_UNDEF) to VKD3D_SM4_RT_TEMP, while ideally that lookup would fail.
> ```diff
> @@ -2838,7 +2855,8 @@ static enum vkd3d_result sm6_parser_init(struct sm6_parser *sm6, const uint32_t
> return ret;
> }
>
> - if (!(sm6->output_params = shader_parser_get_dst_params(&sm6->p, output_signature->element_count)))
> + if (!(sm6->output_params = shader_parser_get_dst_params(&sm6->p, output_signature->element_count))
> + || !(sm6->input_params = shader_parser_get_dst_params(&sm6->p, input_signature->element_count)))
> {
> ERR("Failed to allocate output parameters.\n");
> vkd3d_shader_error(message_context, &location, VKD3D_SHADER_ERROR_DXIL_OUT_OF_MEMORY,
> ```
That makes the error message inaccurate.
> ```diff
> +static inline unsigned int sm6_parser_alloc_ssa_id(struct sm6_parser *sm6)
> +{
> + return sm6->ssa_next_id++;
> +}
> ```
Why is that "static inline"? The main thing it'll do in .c files is to make it harder to spot unused code. We seem to have some more instances of that in both the existing dxil.c code and this MR.
> ```diff
> +static void register_init_with_id(struct vkd3d_shader_register *reg,
> + enum vkd3d_shader_register_type reg_type, enum vkd3d_data_type data_type, unsigned int index)
> +{
> + shader_register_init(reg, reg_type, data_type, 1);
> + reg->idx[0].offset = index;
> +}
> ```
This is pretty minor in the scheme of things, but where is the ID above? I'm guessing it's supposed to be the "index" parameter.
> ```diff
> +static void register_init_ssa_vector(struct vkd3d_shader_register *reg, enum vkd3d_data_type data_type,
> + unsigned int component_count, struct sm6_parser *sm6)
> ...
> +static inline void register_init_ssa_scalar(struct vkd3d_shader_register *reg, const struct sm6_type *type,
> + struct sm6_parser *sm6)
> ```
Why does initialising a SSA vector require a vkd3d_data_type, while initialising a SSA scalar requires a sm6_type? Also, register_init_ssa_vector() is only ever called with a "component_count" of 1.
> ```diff
> +static void instruction_dst_param_init_ssa_scalar_component(struct vkd3d_shader_instruction *ins,
> + unsigned int component_idx, struct sm6_parser *sm6)
> +{
> + struct vkd3d_shader_dst_param *param = instruction_dst_params_alloc(ins, 1, sm6);
> + struct sm6_value *dst = sm6_parser_get_current_value(sm6);
> +
> + dst_param_init_ssa_scalar(param, dst->type, sm6);
> + param->write_mask = VKD3DSP_WRITEMASK_0 << component_idx;
> + dst->u.reg = param->reg;
> +}
> ```
Somewhat like register_init_ssa_vector() above, we're only ever calling instruction_dst_param_init_ssa_scalar_component() with a "component_idx" of 0.
I'm guessing future patches will make some of these issues go away, but that's not ideal.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/320#note_46057
On Tue Sep 19 18:27:47 2023 +0000, Aidan Khoury wrote:
> This is needed in case the `-Wunused-variable` is used with clang
> compiler frontend. The Windows Patch API passes this variable - see https://learn.microsoft.com/en-us/previous-versions/bb417345(v=msdn.10)#nor….
> Though it is unused, I would like to keep it to maintain compatibility
> with the Windows API.
I assume you mean -Wunused-parameter, since -Wunused-variable alone shouldn't warn on parameters.
I don't think -Wunused-parameter is reasonable to enable for Wine. The Windows API has far, far too many unused parameters for annotating them all to be worthwhile.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_46053
Rémi Bernon (@rbernon) commented about dlls/windows.applicationmodel/tests/model.c:
> if (SUCCEEDED(test_register_package( manager, &package )))
> {
> test_execute_package( package );
> + test_PackageStatics();
This won't work like that. At this point the test has indeed installed a package (and executed its application), but this code still executes in the context of the normal test executable.
You should add the tests in `application.c` if you want to the behavior from within an packaged application. For instance you could have a `test_PackageStatics` there too, which would expect the current package to be always valid.
Of course, we don't support running this on Wine yet, because we don't support running packaged applications, so the tests are entirely skipped. But at least it will show us native's behavior.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3548#note_46048
On Tue Sep 19 20:06:50 2023 +0000, Yuxuan Shui wrote:
> it fails on Windows because I didn't bother to remove that particular
> `CHECK_CALLED`. the reason it fails is because Windows' http protocol
> _does not_ handle redirect.
> And we are trying to figure out how the native urlmon is different, in
> that case isn't this kind of test failures _helpful_? And this MR is a
> draft, I wasn't expect it to be merged in this form anyway.
> I'll reopen this.
In addition calling the test "not interesting" because it fails that particular test makes no sense to me. I feel you are being overly dismissive, and I don't know why. Did I do something wrong to upset you?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3818#note_45927
On Tue Sep 19 19:01:40 2023 +0000, Jacek Caban wrote:
> First of all, your test fails on Windows, so it's not interesting in
> current form. I will add more comments in !3725.
it fails on Windows because I didn't bother to remove that particular `CHECK_CALLED`. the reason it fails is because Windows' http protocol _does not_ handle redirect.
And we are trying to figure out how the native urlmon is different, in that case isn't this kind of test failures _helpful_? And this MR is a draft, I wasn't expect it to be merged in this form anyway.
I'll reopen this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3818#note_45926
This clears up much of the todo list for mspatcha. GetFilePatchSignature* and NormalizeFileForPatchSignature have now been implemented in these changes.
These changes bring better support for things like the Adobe Acrobat installer without the need for things like the winetricks mspatcha.dll native dll override. Still needed is support for interleaved streams in the LZXD decompression logic, however this is a great start to better supporting software installers that use the Windows interface for creating and applying patches to files.
This is the beginning of the fixes required for bug 12501: https://bugs.winehq.org/show_bug.cgi?id=12501
--
v10: mspatcha: Fix new file buffer local variable assignment
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870
If DISABLEAUTOREDIRECTS is set in BINDINFO options, urlmon does not set HTTP verb to GET when handling redirections.
Although HTTP specification is vague on the correct behaviour here, many web servers expect this. This is what's causing the "400 Bad Request" error when user tries to log into GMail accounts using Outlook.
--
v5: urlmon: test redirection of POST requests
urlmon: fix HTTP redirects when auto redirection is disabled
https://gitlab.winehq.org/wine/wine/-/merge_requests/3725
Patches for debug printing in the tests are also included in this MR. I've been maintaining a separate set of patches for this, but these would make it a lot easier for me or anyone else in the future to write tests IMO.
--
v2: uiautomationcore: Don't return oleacc proxy IAccessibles from GetIAccessible for MSAA providers.
uiautomationcore: Implement IRawElementProviderFragment::get_FragmentRoot for MSAA providers
https://gitlab.winehq.org/wine/wine/-/merge_requests/3890
This clears up much of the todo list for mspatcha. GetFilePatchSignature* and NormalizeFileForPatchSignature have now been implemented in these changes.
These changes bring better support for things like the Adobe Acrobat installer without the need for things like the winetricks mspatcha.dll native dll override. Still needed is support for interleaved streams in the LZXD decompression logic, however this is a great start to better supporting software installers that use the Windows interface for creating and applying patches to files.
This is the beginning of the fixes required for bug 12501: https://bugs.winehq.org/show_bug.cgi?id=12501
--
v8: mspatcha: Fix progress callback behaviour
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870
This clears up much of the todo list for mspatcha. GetFilePatchSignature* and NormalizeFileForPatchSignature have now been implemented in these changes.
These changes bring better support for things like the Adobe Acrobat installer without the need for things like the winetricks mspatcha.dll native dll override. Still needed is support for interleaved streams in the LZXD decompression logic, however this is a great start to better supporting software installers that use the Windows interface for creating and applying patches to files.
This is the beginning of the fixes required for bug 12501: https://bugs.winehq.org/show_bug.cgi?id=12501
--
v5: mspatcha: Add unit tests for NormalizeFileForPatchSignature and GetFilePatchSignature*
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870
--
v2: winegstreamer: Also return output with 2 channels for multichannel inputs from AAC decoder.
winegstreamer: Validate maximum channel count in _SetInputType in AAC decoder.
winegstreamer: Correct output available types attrs in AAC decoder for channel count > 2.
winegstreamer: Handle missing or zero channel count in _GetOutputAvailableType in AAC decoder.
mf/tests: Add tests for AAC decoder with different input number of channels.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3884
Patches for debug printing in the tests are also included in this MR. I've been maintaining a separate set of patches for this, but these would make it a lot easier for me or anyone else in the future to write tests IMO.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3890
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v28: server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
This corresponds to vkd3d as of commit
e597b0d80f39f716a8740cb0be55edc78f4599d6.
This brings in a function signature fix for the implementation
of ID3D12CommandQueue::UpdateTileMappings() as well, from
vkd3d commit e98e6c9b530995e68bd019a3319d90223ed864cf.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3889
On Tue Sep 19 08:41:58 2023 +0000, Chip Davis wrote:
> Can you set this up to let me and possibly Bill Hollings know if CI on
> Mac breaks and it's not your fault? I'd really appreciate knowing when
> we've broken things for you.
I don't think this is the most appropriate place to detect MoltenVK regressions, because we don't use MoltenVK from git, but a released version, which I think is installed through brew. I don't even think it is the latest released version. At any rate, even when there is a regression I don't have an automated way to know whether what's broken is vkd3d or MoltenVK. Also, notice that currently vkd3d is broken in many ways on top of MoltenVK (the CI job is marked as allowed to fail for this reason); test `d3d12` even segfaults (I am preparing some patches for that). Before this can give a useful signal vkd3d tests should be appropriately marked as todo on MoltenVK, so that actual breakages can be detected. Eventually I hope to do that, but it might take a while (for example, I've been planning to do the same for Intel and NVIDIA on Linux, which have similarly been broken for a long time if not forever; and it hasn't happened yet). Of course we'll be happy to take patches, if you have so
me bandwidth for that.
To address my first concern, I'd suggest to avoid using this specific project, but rather set up another one that tracks both vkd3d and MoltenVK development branches, and run the tests each time any of the two projects is committed to: this might help to give an idea of which project broke it when there is a problem. Or maybe run the stable vkd3d on the development MoltenVK, I don't know. I can help to set this up, but marking the tests as todo must be done before.
BTW, the macOS runner available here is based on an Intel chip. In your experience, can testing on Intel be considered representative of the M1 behavior too, or should we come up with an M1 runner too?
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/328#note_45856
--
v3: oleaut32: Use CRT allocation functions in typelib.c.
oleaut32: Use CRT allocation functions in olepicture.c.
oleaut32: Use CRT allocation functions in hash.c.
oleaut32: Use CRT allocation functions in connpt.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3617
Certain characters are considered by GetTextExtentExPointA/W to have no width, even if they have a non-zero width and a shape in the font. This MR attempts to bring Wine's implementation of these functions closer to native behavior, though I was not able to get it anywhere near perfect.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3876
This patch-set adds the definitions and struct modifications required to eventually implement `FileRenameInformationEx` and `FileLinkInformationEx`.
The initial tests are copies of the tests for `FileRenameInformation` and `FileLinkInformation`, but with the `ReplaceIfExists` field replaced with the equivalient `Flag` value: `FILE_RENAME_REPLACE_IF_EXISTS` or `FILE_LINK_REPLACE_IF_EXISTS` respectively.
--
v4: ntdll/tests: Test both FileLinkInformation and FileLinkInformationEx in test_file_link_information.
include: Add flags to FILE_LINK_INFORMATION used by FileLinkInformationEx.
ntdll/tests: Test both FileRenameInformation and FileRenameInformationEx in test_file_rename_information.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3836
Make functions ntlea needs to patch hotpatchable. And add a asm wrapper for `GetWindowLongA` to workaround an assumption ntlea made.
--
v7: user32: add hotpatchable wrapper for GetWindowLongA
https://gitlab.winehq.org/wine/wine/-/merge_requests/3855
Make functions ntlea needs to patch hotpatchable. And add a asm wrapper for `GetWindowLongA` to workaround an assumption ntlea made.
--
v6: user32: add hotpatchable wrapper for GetWindowLongA
https://gitlab.winehq.org/wine/wine/-/merge_requests/3855
Make functions ntlea needs to patch hotpatchable. And add a asm wrapper for `GetWindowLongA` to workaround an assumption ntlea made.
--
v5: user32: add hotpatchable wrapper for GetWindowLongA
https://gitlab.winehq.org/wine/wine/-/merge_requests/3855
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v27: server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
--
v5: gdiplus/tests: add tests of InterpolationMode Bilinear for GdipDrawImagePointsRect
gdiplus: implement PixelOffsetMode Half and HighQuality for GdipDrawImagePointsRect
https://gitlab.winehq.org/wine/wine/-/merge_requests/3877
This patch-set adds the definitions and struct modifications required to eventually implement `FileRenameInformationEx` and `FileLinkInformationEx`.
The initial tests are copies of the tests for `FileRenameInformation` and `FileLinkInformation`, but with the `ReplaceIfExists` field replaced with the equivalient `Flag` value: `FILE_RENAME_REPLACE_IF_EXISTS` or `FILE_LINK_REPLACE_IF_EXISTS` respectively.
--
v3: ntdll/tests: Test both FileLinkInformation and FileLinkInformationEx in test_file_link_information.
include: Add flags to FILE_LINK_INFORMATION used by FileLinkInformationEx.
ntdll/tests: Test both FileRenameInformation and FileRenameInformationEx in test_file_rename_information.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3836
On Mon Sep 18 17:52:49 2023 +0000, Zebediah Figura wrote:
> Why are we adding one here? That doesn't look right.
I think I see what the intent is, but it is unnecessarily 'clever'. It would be clearer to use something like a `BOOL modified`, and ultimately `return modified ? NORMALIZE_RESULT_SUCCESS_MODIFIED : NORMALIZE_RESULT_SUCCESS;`
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_45774
Make functions ntlea needs to patch hotpatchable. And add a asm wrapper for `GetWindowLongA` to workaround an assumption ntlea made.
--
v3: user32: add hotpatchable wrapper for GetWindowLongA
https://gitlab.winehq.org/wine/wine/-/merge_requests/3855