Some fixes to valid clangd warnings, since I am using it as linter.
Also, I am removing enum hlsl_error_level on 4/6, since it doesn't seem to be meant to be used anywhere after 3/6.
--
v2: vkd3d-shader/d3dbc: Use D3DSIO_TEXKILL instead of VKD3D_SM1_OP_TEXKILL (clangd).
vkd3d-shader/hlsl: Remove enum hlsl_error_level (clangd).
vkd3d-shader/tpf: Avoid translations to D3DDECLUSAGE and back (clangd).
vkd3d-shader: Remove unnecessary fallthroughs (clangd).
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/402
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v9: vkd3d-shader/tpf: Write out 'switch' statements.
vkd3d-shader/hlsl: Add a pass to validate switch cases blocks.
vkd3d-shader/hlsl: Add a pass to remove unreachable code.
vkd3d-shader/hlsl: Add copy propagation logic for switches.
vkd3d-shader/hlsl: Validate break/continue context.
vkd3d-shader/hlsl: Check for duplicate case statements.
vkd3d-shader/hlsl: Add initial support for parsing 'switch' statements.
tests: Add some tests for the 'switch' statements.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/361
The PE build uses FlsAlloc(), which for our purposes makes no difference vs TlsAlloc(), and allows the use of a destruction callback.
--
v3: vkd3d: Replace the descriptor object cache with a thread-local implementation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/384
A TLS index is allocated for each device object. We could use a global TLS, but that would share caches for all devices. I'm not sure if that's a problem. One index per device means freed indices must be recycled, which requires a global mutex, but a global TLS index would also need a global mutex.
This currently leaks cache memory when a device is freed. To fix this, allocations must be tracked. A global cache is more difficult to free, which is not normally an issue, but it is when using valgrind.
--
v2: vkd3d: Replace the descriptor object cache with a thread-local implementation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/384
Goes atop MRs 346 and 372. The last five commits are of this MR.
--
v4: vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
vkd3d-shader/dxil: Handle multi-row signature elements.
vkd3d-shader/dxil: Handle signature element additional tag/value pairs.
vkd3d-shader/dxil: Read the DXIL input and output signatures.
vkd3d-shader/dxil: Validate the entry point info.
vkd3d-shader/dxil: Read DXIL metadata named nodes.
vkd3d-shader/dxil: Read DXIL metadata kinds.
vkd3d-shader/dxil: Read DXIL metadata values.
vkd3d-shader/dxil: Read DXIL metadata nodes.
vkd3d-shader/dxil: Read DXIL metadata strings.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/388
This MR improves window management related behavior and adds support for more scenarios.
Some highlights (please see the full commit list and messages for more info):
1. Better support for tiled states.
2. Detect and handle fullscreen windows.
3. Increased robustness against state disagreements between Wine and the Wayland compositor.
4. Move top-level windows to (0,0) (using that fixed point for now, we will later generalize this mechanism for multiple monitors), in order to:
a. maximize the accessible mouse input region (which may be clipped in Windows virtual screen space, but still accessible in Wayland space).
b. introduce the basic mechanism to allow windows applications to (very roughly!) track which output(s) they are really on (to be continued in the full multi-monitor form).
Although (4) is not a perfect solution for the lack of absolute positioning, it has worked well in practice in its full, multi-monitor implementation (i.e., in the experimental branch). I wonder if for (4a) in particular we can do better, e.g., by being able to emit input that circumvents the normal virtual screen clipping. Is there a way to do this already? If not, do you think that such an approach would be a feasible and acceptable way forward, or is virtual screen input clipping fundamentally baked in the current core design and assumptions?
Thanks!
--
v2: winewayland.drv: Avoid resizing fullscreen windows.
winewayland.drv: Rename wayland_surface_configure_is_compatible for consistency.
winewayland.drv: Use surface geometry to satisfy state size constraints.
winewayland.drv: Handle application-initiated fullscreen state.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4014
Some fixes to valid clangd warnings, since I am using it as linter.
Also, I am removing enum hlsl_error_level on 4/6, since it doesn't seem to be meant to be used anywhere after 3/6.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/402
Implements asin, acos, atan, and atan2.
Also includes some tests in a new test file.
One possible problem here is that I'm not sure how to test what Microsoft's atan and atan2 outputs are in boundary cases like atan2(1, 0). I've made the test suites adhere with the calculator program I've been using (Qalculate, which I assume is using libc's atan2).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55154
--
v2: vkd3d-shader/hlsl: Implement atan2.
vkd3d-shader/hlsl: Implement atan.
vkd3d-shader/hlsl: Implement acos and asin trig intrinsics.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/364
Okay, I will revert those specific tests.
Generating the PE binaries won't be such a problem, however generating patch data that works on a generated PE is a problem. This would require writing implementations for most of mspatchc in order to properly generate patch data. I'm curious how the original author of the mspatcha implementation @cmccarthy generated the patch data
Any help with this would be very valuable and appreciated. I am trying to fix a 15 year old bug report with these changes so that people can finally install software without the need for manually installing the native Microsoft mspatcha binary.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_48358
If _NET_WM_FULLSCREEN_MONITORS is set then the property needs to be updated because it can't
be deleted by sending a _NET_WM_FULLSCREEN_MONITORS client message to the root window
according to the wm-spec version 1.5. Having the window spanning more than two monitors also
needs the property set. In other cases, _NET_WM_FULLSCREEN_MONITORS doesn't need to be set.
What's more, setting _NET_WM_FULLSCREEN_MONITORS adds a constraint on Mutter so that such a
window can't be moved to another monitor by using the Shift+Super+Up/Down/Left/Right
shortcut. So the property should be added only when necessary.
--
v2: winex11.drv: Set _NET_WM_FULLSCREEN_MONITORS only when necessary.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4063
The failed 32bit tests are the following:
```
domdoc.c:2521: Test failed: Unexpected hr 0x1.
filtergraph.c:635: Test failed: Got hr 0x40242.
filtergraph.c:571: Test failed: Got hr 0x80004005.
speech.c:1386: Test failed: Wait for block_thread failed.
```
Unrelated to the patch + they've been failing all across different MRs here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4065#note_48346
On Wed Oct 11 11:05:32 2023 +0000, Chip Davis wrote:
> According to [docs][1], `SetBrushOrgEx()` is supposed to affect the
> *next* brush that is selected into the device context. It might be
> interesting, then, to see what happens when a brush is selected into the
> DC after calling `SetBrushOrgEx()`.
> [1]: https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setbru…
That's not reflected by EMF recording, and will need some rendering tests. It's best to have a bug report for that so it's not forgotten.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4058#note_48338
First part of the continuation of the implementation of non-constant offset dereferences (a.k.a. relative addressing) for SM4, now that we use vsir registers in tpf.c.
As a quick recap: while parsing HLSL we are expressing derefs as paths, and then we are lowering these paths into a single offset node (which is closer to the bytecode) using the replace_deref_path_with_offset() pass, right before register allocation.
This first part of the series splits this offset node into 2 parts:
- A constant uint, which will be called hlsl_deref.offset_const.
- A non-hlsl_ir_constant offset node that will only be present when we need relative addressing, that we will end up calling hlsl_deref.offset_rel.
Both these fields will be analog to the ones used in vsir register indexes, vkd3d_shader_register_index.rel_addr and vkd3d_shader_src_param.offset respectively, which is something we need for the second part of this series.
The following patches are in my [nonconst-offsets-8-part](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/n… branch, if something is not clear in this series, it may be worth skimming through them.
Supersedes !229.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/396
Which may be different from the last desktop cursor handle.
This makes the behavior better match the old winex11 behavior, which queried
the current thread input cursor handle on every mouse move to sync it with X11,
although it contradicts MSDN documentation which states that the cursor handle
is global.
This fixes the X11 cursor being visible in "Deus Ex: GOTY Edition".
--
v3: server: Send WM_WINE_SETCURSOR with the thread input cursor handle.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4068
This adds support for missing architectures in widl, providing full coverage of current Debian architectures and ports.
I’m aware this restores SPARC which was removed in 2017; if that’s a problem I can remove that part of the patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3997
Which may be different from the last desktop cursor handle.
This makes the behavior better match the old winex11 behavior, which queried
the current thread input cursor handle on every mouse move to sync it with X11,
although it contradicts MSDN documentation which states that the cursor handle
is global.
This fixes the X11 cursor being visible in "Deus Ex: GOTY Edition".
--
v2: server: Send WM_WINE_SETCURSOR with the thread input cursor handle.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4068
If _NET_WM_FULLSCREEN_MONITORS is set then the property needs to be updated because it can't
be deleted by sending a _NET_WM_FULLSCREEN_MONITORS client message to the root window
according to the wm-spec version 1.5. Having the window spanning more than two monitors also
needs the property set. In other cases, _NET_WM_FULLSCREEN_MONITORS doesn't need to be set.
What's more, setting _NET_WM_FULLSCREEN_MONITORS adds a constraint on Mutter so that such a
window can't be moved to another monitor by using the Shift+Super+Up/Down/Left/Right
shortcut. So the property should be added only when necessary.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4063
On Fri Oct 6 16:29:41 2023 +0000, Aidan Khoury wrote:
> I used binary resources instead of header files full of an array of
> bytes: de05aea3c1a1213de90bbf433e8258753b1b60aa
> I borrowed this technique from other test cases I found, specifically in mf.dll
We can't ship binaries copied from some random installer. In any case this will need a lot more test cases for all the various code paths, so you'll need to be able to generate the binaries from the test.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_48313
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v7: vkd3d-shader/tpf: Write out 'switch' statements.
vkd3d-shader/hlsl: Initial support for 'switch' statement.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/361
Goes atop MRs 346 and 372. The last five commits are of this MR.
--
v3: vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
vkd3d-shader/dxil: Handle multi-row signature elements.
vkd3d-shader/dxil: Handle signature element additional tag/value pairs.
vkd3d-shader/dxil: Read the DXIL input and output signatures.
vkd3d-shader/dxil: Validate the entry point info.
vkd3d-shader/dxil: Read DXIL metadata named nodes.
vkd3d-shader/dxil: Read DXIL metadata kinds.
vkd3d-shader/dxil: Read DXIL metadata values.
vkd3d-shader/dxil: Read DXIL metadata nodes.
vkd3d-shader/dxil: Read DXIL metadata strings.
vkd3d-shader/dxil: Emit an error on allocation failure in dxil_record_to_string().
vkd3d-shader/dxil: Read global constants in sm6_parser_globals_init().
vkd3d-shader/dxil: Read immediate constant arrays.
tests/shader-runner: Test shaders with dxcompiler.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/388
Goes atop MR 346 and 400, and therefore is a draft until they are upstream.
--
v9: vkd3d-shader/dxil: Read the DXIL input and output signatures.
vkd3d-shader/dxil: Validate the entry point info.
vkd3d-shader/dxil: Read DXIL metadata named nodes.
vkd3d-shader/dxil: Read DXIL metadata kinds.
vkd3d-shader/dxil: Read DXIL metadata values.
vkd3d-shader/dxil: Read DXIL metadata nodes.
vkd3d-shader/dxil: Read DXIL metadata strings.
vkd3d-shader/dxil: Emit an error on allocation failure in dxil_record_to_string().
vkd3d-shader/dxil: Read global constants in sm6_parser_globals_init().
vkd3d-shader/dxil: Read immediate constant arrays.
tests/shader-runner: Test shaders with dxcompiler.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/372
Goes atop MRs 346 and 372. The last five commits are of this MR.
--
v2: vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
vkd3d-shader/dxil: Handle multi-row signature elements.
vkd3d-shader/dxil: Handle signature element additional tag/value pairs.
vkd3d-shader/dxil: Read the DXIL input and output signatures.
vkd3d-shader/dxil: Validate the entry point info.
vkd3d-shader/dxil: Read DXIL metadata named nodes.
vkd3d-shader/dxil: Read DXIL metadata kinds.
vkd3d-shader/dxil: Read DXIL metadata values.
vkd3d-shader/dxil: Read DXIL metadata nodes.
vkd3d-shader/dxil: Read DXIL metadata strings.
vkd3d-shader/dxil: Emit an error on allocation failure in dxil_record_to_string().
vkd3d-shader/dxil: Read global constants in sm6_parser_globals_init().
vkd3d-shader/dxil: Read immediate constant arrays.
tests/shader-runner: Test shaders with dxcompiler.
tests/shader-runner: Replace immediate shader type strings with an enum.
tests/shader-runner: Do not exit if a 'require' directive is not met.
tests/shader-runner: Handle individual keywords in shader directives.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/388
Goes atop MR 346 and 400, and therefore is a draft until they are upstream.
--
v8: vkd3d-shader/dxil: Read the DXIL input and output signatures.
vkd3d-shader/dxil: Validate the entry point info.
vkd3d-shader/dxil: Read DXIL metadata named nodes.
vkd3d-shader/dxil: Read DXIL metadata kinds.
vkd3d-shader/dxil: Read DXIL metadata values.
vkd3d-shader/dxil: Read DXIL metadata nodes.
vkd3d-shader/dxil: Read DXIL metadata strings.
vkd3d-shader/dxil: Emit an error on allocation failure in dxil_record_to_string().
vkd3d-shader/dxil: Read global constants in sm6_parser_globals_init().
vkd3d-shader/dxil: Read immediate constant arrays.
tests/shader-runner: Test shaders with dxcompiler.
tests/shader-runner: Replace immediate shader type strings with an enum.
tests/shader-runner: Do not exit if a 'require' directive is not met.
tests/shader-runner: Handle individual keywords in shader directives.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/372
This goes on top of MR 345.
--
v25: tests/shader-runner: Test shaders with dxcompiler.
tests/shader-runner: Replace immediate shader type strings with an enum.
tests/shader-runner: Do not exit if a 'require' directive is not met.
tests/shader-runner: Handle individual keywords in shader directives.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/346
On Wed Oct 11 01:39:28 2023 +0000, Zhiyi Zhang wrote:
> In that case, you should implement them. For ShouldAppsUseDarkMode(),
> there is a recent MR at
> https://gitlab.winehq.org/wine/wine/-/merge_requests/3959 that
> implements ShouldSystemUseDarkMode(). I think ShouldAppsUseDarkMode() is
> similar and uses the AppsUseLightTheme registry key. For
> AllowDarkModeForWindow() and SetPreferredAppMode(), they can be
> implemented as stubs for the moment. I also came across
> https://gist.github.com/rounk-ctrl/b04e5622e30e0d62956870d5c22b7017
> which lists their usage.
It looks to me that AllowDarkModeForWindow() and SetPreferredAppMode() set window-specific properties so that dark mode can be enabled/disabled for individual windows. And ShouldAppsUseDarkMode() should consider that. For the moment, returning the AppsUseLightTheme value for ShouldAppsUseDarkMode() is probably enough.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4043#note_48281
On Wed Oct 11 01:39:28 2023 +0000, Louis Lenders wrote:
> Hi Zhiyi, it seems it's all more complicated then I thought. The tests
> failed and it seems i put the wrong function names at those ordinals.
> The thread below at Autohotkey suggests that the ordinals belong to some
> undocumented functions ShouldAppsUseDarkMode, AllowDarkModeForWindow
> and SetPreferredAppMode, apparently they can only be imported by ordinal.
> So should I now only test that they can be imported by ordinal
> (something like
> proc = GetProcAddress(uxtheme, MAKEINTRESOURCEA(func[i].ordinal));
> ok(proc, "getting function by ordinal failed"); )?
> )
> autohotkey thread: https://www.autohotkey.com/boards/viewtopic.php?t=94661&start=20
In that case, you should implement them. For ShouldAppsUseDarkMode(), there is a recent MR at https://gitlab.winehq.org/wine/wine/-/merge_requests/3959 that implements ShouldSystemUseDarkMode(). I think ShouldAppsUseDarkMode() is similar and uses the AppsUseLightTheme registry key. For AllowDarkModeForWindow() and SetPreferredAppMode(), they can be implemented as stubs for the moment. I also came across https://gist.github.com/rounk-ctrl/b04e5622e30e0d62956870d5c22b7017 which lists their usage.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4043#note_48279
We have no means of stopping the thread from DllMain on
DLL_PROCESS_DETACH without having a race condition - waiting on the
thread itself is not an option due to the loader lock.
The best we can do is just never unload the DLL as long as the thread is
active which is forever.
This fixes crashes in Mighty Switch Force! Collection while controllers
are unplugged - the game loads and frees xinput in a loop.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4065
Hi Zhiyi, it seems it's all more complicated then I thought. The tests failed and it seems i put the wrong function names at those ordinals.
The thread below at Autohotkey suggests that the ordinals belong to some undocumented functions ShouldAppsUseDarkMode, AllowDarkModeForWindow and SetPreferredAppMode, apparently they can only be imported by ordinal.
So should I now only test that they can be imported by ordinal (something like
proc = GetProcAddress(uxtheme, MAKEINTRESOURCEA(func[i].ordinal));
ok(proc, "getting function by ordinal failed"); )?
)
autohotkey thread: https://www.autohotkey.com/boards/viewtopic.php?t=94661&start=20
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4043#note_48238
--
v5: uiautomationcore: Use EVENT_OBJECT_DESTROY to remove HWNDs from the COM API focus change HWND map.
uiautomationcore: Use EVENT_OBJECT_FOCUS to advise HWND providers of focus change events in the COM API.
uiautomationcore: Query EVENT_OBJECT_FOCUS HWND for a serverside provider if there is a registered focus change event handler.
uiautomationcore/tests: Add tests for IUIAutomationFocusChangedEventHandler event advisement behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4024
I marked this a draft because it may be a somewhat orthogonal step, but IRRC @giomasce suggested it.
While a deref's data type can be computed from the variable's data type
as long as the deref is still represented as a path (as we did with
hlsl_deref_get_type()), we need the deref.data_type field for when the
deref is represented as an offset.
While we could get rid of this deref.data_type in the future, if we manage to transform
the HLSL IR instructions directly to VSIR withot requiring lowering the
derefs to their offset representation, this would take a while.
So, this patch makes the deref.data_type field available during the
whole lifetime of the deref. Which makes deref.data_type easier to
understand (since it can be used anytime now) and we no longer have
to call hlsl_deref_get_type().
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/343
Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v9: Revert "ntdll: Support relocating the main exe."
quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Implement a little more of IAMStreamSelect in CLSID_MPEG1Splitter.
winegstreamer: Implement CLSID_CMpegVideoCodec.
winegstreamer: Add program stream and video output support to CLSID_MPEG1Splitter.
winegstreamer: Add WG_MAJOR_TYPE_VIDEO_MPEG1 media type.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938
```
+ void *proc;
+ int i;
+ HMODULE uxtheme = GetModuleHandleA("uxtheme.dll");
+ static const struct
+ {
+ const char *name;
+ int ordinal;
+ }
+ func[] =
+ {
+ {"DrawThemeBackgroundEx", 47},
+ {"IsThemeDialogTextureEnabled", 132},
+ {"IsThemePartDefined", 133},
+ {"SetThemeAppProperties", 135}
+ };
```
Let's put the static const test data first.
And let's sort the declarations, like this.
```
+ HMODULE uxtheme;
+ void *proc;
+ int i;
+
+ uxtheme= GetModuleHandleA("uxtheme.dll");
```
```
+ for (i = 0; i < ARRAY_SIZE(func); i++)
+ {
+ proc = GetProcAddress(uxtheme, MAKEINTRESOURCEA(func->ordinal));
+ ok(proc == GetProcAddress(uxtheme, func->name), "Expected %s at ordinal %u\n", func->name, func->ordinal);
+ }
```
You're not using i at all so you're just testing the first function.
```ok(proc == GetProcAddress(uxtheme, func->name), "Expected %s at ordinal %u\n", func->name, func->ordinal);```
"Expected %s at ordinal %u\n" -> "Expected %s at ordinal %d.\n"
You can remove the ordinal tests for DrawThemeBackgroundEx() in test_DrawThemeBackgroundEx().
Thank you for working on this by the way.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4043#note_48211