The serie intent is to fix unexpected paths in module's list:
This happens:
- when running under old / (new) wow64
- when main module is located under the syswow64 directory
- the 32 bit modules are stored in LdrData (and then exposed through
a couple of ways) under syswow64 (they are normally stored under
system32, letting the redirection come into play when needed)
This triggers a couple of errors in winetest (as we're using
c:\windows\syswow64\msinfo32.exe in many tests to trigger a wow64
process from a winetest program).
This is the fix awaited in MR!2497.
@julliard: I'm not 100% happy with the fix itself by reintroducting
ref to the redirected DLLs in ntdll/PE but couldn't find a better idea.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2578
This MR contains two somewhat related commits/fixes for regressions that were made apparent in https://bugs.winehq.org/show_bug.cgi?id=54781.
1. The adapter ids used by the host and settings handlers are not guaranteed to be compatible, so ensure we are using the proper id with each
handler.
Note that although the possibly incompatible id was already used in `settings_handler.get_modes()` before, the settings handler was ignoring it anyway for `get_modes()` in the case it was really incompatible (e.g., using host handler xrandr 1.4, settings handler xrandr 1.0), . The problem manifests now since we are additionally calling `settings_handler.get_current_mode()` which does check the id value (e.g., in xrandr 1.0 to differentiate primary vs non-primary).
2. The virtual desktop get_current_mode() implementation recurses into win32u (through NtUserGetPrimaryScreenRect) causing a deadlock if we call it from within UpdateDisplayDevices. There is a way to avoid the deadlock if we get the current_modes before calling add_gpu(), but we don't need to get and update the win32u current/registry in the virtual desktop case anyway, so skip the call completely instead.
--
v4: winex11.drv: Use a distinct type for the settings id.
winex11.drv: Do not call desktop get_current_mode() from UpdateDisplayDevices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2593
I'm not 100% sure all of them are the same thing, and I can only reproduce one failure locally, but I suspect they might. In any case if the foreground window is wrong it's simply not going to work.
--
v2: dinput/tests: Mark some tests as flaky to workaround fvwm bug.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2599
The last patch is a huge optimization to what is done in patch 2. Without that the sample is first copied from GPU to CPU each time wg_transform_read_mf() locks the buffer (allocating extra linear buffer on the way) and then copies the data back to GPU. That happens even if there is no sample available from wg_transform. With the last patch there is just one memory copy to the (write-only) locked DXGI surface buffer. And CPU to GPU texture transfer (which would be there anyway in most cases on software path as most of the apps are going to get the image to GPU anyway). In principle we could also skip the explicit staging texture and use _UpdateSubresource instead directly from h264 decoder, but this is currently not supported in wined3d for chroma formats and the overall difference between _UpdateSubresource and explicit mapped staging texture is not that great probably.
--
v2: winegstreamer: Pass temporary sample to wg_transform_read_mf() in h264 decoder.
winegstreamer: Provide samples if DXGI device manager is set in h264 decoder.
winegstreamer: Process MFT_MESSAGE_SET_D3D_MANAGER in h264 decoder.
mf/tests: Test h264 decoder with dxgi device manager.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2587
This MR contains two somewhat related commits/fixes for regressions that were made apparent in https://bugs.winehq.org/show_bug.cgi?id=54781.
1. The adapter ids used by the host and settings handlers are not guaranteed to be compatible, so ensure we are using the proper id with each
handler.
Note that although the possibly incompatible id was already used in `settings_handler.get_modes()` before, the settings handler was ignoring it anyway for `get_modes()` in the case it was really incompatible (e.g., using host handler xrandr 1.4, settings handler xrandr 1.0), . The problem manifests now since we are additionally calling `settings_handler.get_current_mode()` which does check the id value (e.g., in xrandr 1.0 to differentiate primary vs non-primary).
2. The virtual desktop get_current_mode() implementation recurses into win32u (through NtUserGetPrimaryScreenRect) causing a deadlock if we call it from within UpdateDisplayDevices. There is a way to avoid the deadlock if we get the current_modes before calling add_gpu(), but we don't need to get and update the win32u current/registry in the virtual desktop case anyway, so skip the call completely instead.
--
v3: winex11.drv: Do not call desktop get_current_mode() from UpdateDisplayDevices.
winex11.drv: Use the proper id with the settings handler.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2593
Hi Yeshun, you don't need to regularly rebase the MR on top of the latest master. Because this area of code is largely undocumented, to help this MR gets in, you need to add a test, even if it might not be easy. I think you can use some of the example codes in NCALRPC_example. Thanks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2305#note_29113
On Tue Apr 4 19:02:38 2023 +0000, Zebediah Figura wrote:
> It's hard for me to feel like this is an improvement, when we are now
> adding an extra parameter to every call, and also using some
> undocumented Windows functions that, to the reader, might have some
> obscure different semantics.
Based on that feedback, I am closing this merge request in favor of !2590, which at least gets rid of the duplicate implementation of wcsdup.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1746#note_29106
The last patch is a huge optimization to what is done in patch 2. Without that the sample is first copied from GPU to CPU each time wg_transform_read_mf() locks the buffer (allocating extra linear buffer on the way) and then copies the data back to GPU. That happens even if there is no sample available from wg_transform. With the last patch there is just one memory copy to the (write-only) locked DXGI surface buffer. And CPU to GPU texture transfer (which would be there anyway in most cases on software path as most of the apps are going to get the image to GPU anyway). In principle we could also skip the explicit staging texture and use _UpdateSubresource instead directly from h264 decoder, but this is currently not supported in wined3d for chroma formats and the overall difference between _UpdateSubresource and explicit mapped staging texture is not that great probably.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2587
The adapter ids used by the host and settings handlers are not guaranteed to be compatible, so ensure we are using the proper id with each
handler.
Note that although the possibly incompatible id was already used in `settings_handler.get_modes()` before, the settings handler was ignoring it anyway for `get_modes()` in the case it was really incompatible (e.g., using host handler xrandr 1.4, settings handler xrandr 1.0), . The problem manifests now since we are additionally calling `settings_handler.get_current_mode()` which does check the id value (e.g., in xrandr 1.0 to differentiate primary vs non-primary).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis(a)collabora.com>
Fixes: 4232312dffe1cd115aa6bfd755f5b7c6a403e3fc
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54781
--
v2: winex11.drv: Do not call desktop get_current_mode() from UpdateDisplayDevices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2593
The adapter ids used by the host and settings handlers are not guaranteed to be compatible, so ensure we are using the proper id with each
handler.
Note that although the possibly incompatible id was already used in `settings_handler.get_modes()` before, the settings handler was ignoring it anyway for `get_modes()` in the case it was really incompatible (e.g., using host handler xrandr 1.4, settings handler xrandr 1.0), . The problem manifests now since we are additionally calling `settings_handler.get_current_mode()` which does check the id value (e.g., in xrandr 1.0 to differentiate primary vs non-primary).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis(a)collabora.com>
Fixes: 4232312dffe1cd115aa6bfd755f5b7c6a403e3fc
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54781
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2593
include: _InterlockedExchangePointer and _InterlockedCompareExchangePointer are intrinsics in x86 msvc.
I fixed this issue in ad05f33d67, but a40973f20 regressed this again. I was carrying a
patch for quite a while, feeling dejavu.
The msvc ver of 1900 is taken from Boost's interlocked.hpp, which matches MSVC 2015
(toolset version v140). Boost has a comment that claims that in msvc 2012 those
functions were defined in intrin.h, but those defines are broken with Microsoft's
winnt.h.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2591
On Wed Apr 5 09:07:47 2023 +0000, Byeongsik Jeon wrote:
> I tested a bit of code, it appears that fdwInit is also cached during
> IME switching.
Yeah I'm thinking that the entire `INPUTCONTEXT` is probably switched and kept cached, to avoid sharing its contents with a different IME.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_29002
On Tue Apr 4 20:55:46 2023 +0000, Rémi Bernon wrote:
> I guess maybe we'd have to clear the `fdwInit` flag before calling
> `ImeSelect`? As far as I could see in the tests, the `fdwConversion` and
> `fdwSentence` fields aren't modified by imm32 and left for the IME to
> reset or not. It caused some spurious failures before
> 7d03937abe899db810c983779f2566b94d787e8a with the fields keeping the
> values from the default (MS) IME.
> The tests also suggest that the values are cached between different IME
> selections, unlike what Wine is currently doing.
I tested a bit of code, it appears that fdwInit is also cached during IME switching.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_29001
On Tue Apr 4 20:42:52 2023 +0000, Byeongsik Jeon wrote:
> On a recent review, I realized that I hadn't analyzed this issue
> properly, and the problem had already been fixed by another commit.
> https://gitlab.winehq.org/wine/wine/-/commit/f6ddd4ca86672fe2739ea7d1701511…
> The cause of the problem was that the wrong parameter value(new_context)
> was being passed to ImeSelect(). Because of this, ImeSelect() didn't
> work properly and kept the fdwConversion value of the wrong value (fdwConversionCaps).
> For example, in ImeSelect(), fdwConversion is initialized in the
> following routine:
> ```
> if ( !( lpIMC->fdwInit & INIT_CONVERSION ) )
> {
> lpIMC->fdwConversion = IME_CMODE_NATIVE;
> lpIMC->fdwInit |= INIT_CONVERSION;
> }
> ```
> If the IME follows this initialization routine, the values of
> fdwConversion, fdwSentence set in ime_select_ime() will be ignored.
I guess maybe we'd have to clear the `fdwInit` flag before calling `ImeSelect`? As far as I could see in the tests, the `fdwConversion` and `fdwSentence` fields aren't modified by imm32 and left for the IME to reset or not. It caused some spurious failures before 7d03937abe899db810c983779f2566b94d787e8a with the fields keeping the values from the default (MS) IME.
The tests also suggest that the values are cached between different IME selections, unlike what Wine is currently doing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_28984
This fixes a bug when the session topology contains an invalid
source, which makes the session thread to hang and stop executing
commands.
--
v2: mf: Handle errors when subscribing to events.
mf/tests: Test media session error handling.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2496
On Tue Mar 28 10:35:26 2023 +0000, Byeongsik Jeon wrote:
> Saenaru. This is not an MS IME, but a DDK-based open source Korean IME.
> I think you can check this in the Wine test code.
On a recent review, I realized that I hadn't analyzed this issue properly, and the problem had already been fixed by another commit.
https://gitlab.winehq.org/wine/wine/-/commit/f6ddd4ca86672fe2739ea7d1701511…
The cause of the problem was that the wrong parameter value(new_context) was being passed to ImeSelect(). Because of this, ImeSelect() didn't work properly and kept the fdwConversion value of the wrong value (fdwConversionCaps).
For example, in ImeSelect(), fdwConversion is initialized in the following routine:
```
if ( !( lpIMC->fdwInit & INIT_CONVERSION ) )
{
lpIMC->fdwConversion = IME_CMODE_NATIVE;
lpIMC->fdwInit |= INIT_CONVERSION;
}
```
If the IME follows this initialization routine, the values of fdwConversion, fdwSentence set in ime_select_ime() will be ignored.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_28981
Zebediah Figura (@zfigura) commented about dlls/setupapi/devinst.c:
> {
> if (procnameW)
> {
> - procname = strdupWtoA(procnameW + 1);
> + procname = UnicodeToMultiByte(procnameW + 1, CP_ACP);
> coinst_proc = (void *)GetProcAddress(module, procname);
> - heap_free(procname);
> + MyFree(procname);
It's hard for me to feel like this is an improvement, when we are now adding an extra parameter to every call, and also using some undocumented Windows functions that, to the reader, might have some obscure different semantics.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1746#note_28895
The main advantage is that this way we're getting valid DXBC checksums for DXBC blobs generated by d3dcompiler. See also https://bugs.winehq.org/show_bug.cgi?id=54464.
--
v2: d3dcompiler: Use vkd3d_shader_parse_dxbc() in d3dcompiler_shader_reflection_init().
d3dcompiler: Use vkd3d_shader_parse_dxbc() in d3dcompiler_strip_shader().
d3dcompiler: Use vkd3d_shader_parse_dxbc() in d3dcompiler_get_blob_part().
d3dcompiler: Use vkd3d_shader_serialize_dxbc() in d3dcompiler_strip_shader().
d3dcompiler: Use vkd3d_shader_serialize_dxbc() in d3dcompiler_get_blob_part().
d3dcompiler: Store DXBC sections as vkd3d_shader_dxbc_section_desc structures.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2577
Update the gdi_device_manager API to enable drivers to set the current mode (along with the registry mode if not already set) in
UpdateDisplayDevices.
This changes also allows us to remove the driver code that manually changes the registry settings.
--
v6: wineandroid.drv: Set the current mode using gdi_device_manager.
winemac.drv: Set the current mode using gdi_device_manager.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2568
Note: it's anyway wrong to search source files inside modules' path
(a proper fix will require revisiting source file handling).
This fix will actually be sufficient when running wine from within
its build tree.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2583
Update the gdi_device_manager API to enable drivers to set the current mode (along with the registry mode if not already set) in
UpdateDisplayDevices.
This changes also allows us to remove the driver code that manually changes the registry settings.
--
v5: wineandroid.drv: Set the current mode using gdi_device_manager.
winemac.drv: Set the current mode using gdi_device_manager.
winemac.drv: Extract function to get the current mode.
winewayland.drv: Set the current mode using gdi_device_manager.
winex11.drv: Set the current mode using gdi_device_manager.
winex11.drv: Extract function to check devmode equality.
win32u: Support setting the current mode using gdi_device_manager.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2568
Update the gdi_device_manager API to enable drivers to set the current mode (along with the registry mode if not already set) in
UpdateDisplayDevices.
This changes also allows us to remove the driver code that manually changes the registry settings.
--
v4: wineandroid.drv: Set the current mode using gdi_device_manager.
winemac.drv: Set the current mode using gdi_device_manager.
winemac.drv: Extract function to get the current mode.
winewayland.drv: Set the current mode using gdi_device_manager.
winex11.drv: Set the current mode using gdi_device_manager.
win32u: Support setting the current mode using gdi_device_manager.
debug.h: Add debugstr_devmodew() helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2568
Support manually packing constant buffer elements through the `packoffset(·)` syntax.
Support not included yet for simultaneously having semantics, `register(·)`, and `packoffset(·)`, for abnormalities such as:
```hlsl
Texture2D tex;
cbuffer buff
{
float4 a : packoffset(c0);
sampler sam : packoffset(c0) : register(s1) : SEMANTIC;
}
float4 main() : sv_target
{
return tex.Sample(sam, float2(0, 0)) + a;
}
```
but this motivated the addition of the `hlsl_ir_var.offset_reservation` field instead of reusing `hlsl_ir_var.reg_reservation`.
--
v7: vkd3d-shader/hlsl: Consider register() as manual packing for resource fields.
tests: Test packoffset() with resources inside cbuffers.
vkd3d-shader/hlsl: Ignore packoffset() contents for SM1.
vkd3d-shader/hlsl: Don't allow manual and automatic cbuffer offset packing.
vkd3d-shader/hlsl: Detect overlaps in cbuffer offsets.
vkd3d-shader/hlsl: Support packoffset().
vkd3d-shader/hlsl: Parse packoffset().
vkd3d-shader/hlsl: Rename struct hlsl_reg_reservation fields.
tests: Test packoffset().
tests: Test cbuffer element offsets.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/106
This adds several handy X11 utilities, such as xrandr, and some other
window managers, in order to eventually use a different one and avoid
fwvm race conditions.
I think it would be interesting to test with some different WMs than
fvwm, at least because they are more commonly used.
Then, I also think that fvwm has some race conditions, and it causes
spurious focus loss, as https://bugs.winehq.org/show_bug.cgi?id=54594
for instance. I've been running the same test in a tight loop with any
of the other WMs added here (mutter / kwin / openbox) and it is not
reproducing. With fvwm the failure reproduces quickly and systematically.
The xrandr utility would be useful in the future, but only after the
image is updated to a newer xserver-xorg-video-dummy version which
would support multiple screens. It will then be possible to set them
up with the following commands:
```
xrandr --addmode DUMMY1 1024x768 \
--addmode DUMMY2 1024x768
xrandr --output DUMMY0 --auto \
--output DUMMY1 --right-of DUMMY0 --mode 1024x768 \
--output DUMMY2 --right-of DUMMY1 --mode 1024x768
xrandr # to refresh the settings
```
Then I think it doesn't hurt to have it installed in the meantime.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2467