Today, Wine fails to build with musl libc and Linux kernel 5.14 uAPI
header files.
musl libc doesn't supply any definitions for IPX, such as the SOL_IPX
macro. However, it still provides linux/ipx.h from Linux uAPI header
files if it exists.
Linux kernel wouldn't drop linux/ipx.h from uAPI headers until 5.15,
although IPX support has already been marked obsolete since 2018.
Fix this by not defining HAS_IPX if linux/ipx.h has been included but
nothing defines the SOL_IPX macro.
Status of IPX support from other libcs are noted below:
- bionic: netipx/ipx.h does not exist. linux/ipx.h may or may not
exist. Note that sys/socket.h defines SOL_IPX even if linux/ipx.h is
missing.
- glibc: netipx/ipx.h exists. In this case, Wine assumes IPX support
even if the operating system does not support it in runtime.
- BSD variants: netipx/ipx.h may or may not exist. linux/ipx.h does not
exist. Some BSDs supply SO_DEFAULT_HEADERS instead of SOL_IPX.
--
v2: server: Avoid relying on linux/ipx.h to define SOL_IPX.
ws2_32: Avoid relying on linux/ipx.h to define SOL_IPX.
ntdll: Avoid relying on linux/ipx.h to define SOL_IPX.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3428
SPIR-V says this is undefined behaviour, but Direct3D actually specifies that it
should clamp. Most drivers do clamp, but llvmpipe does not. Hence this fixes a
couple of tests with llvmpipe.
This does of course add overhead to the ftou instruction, but I cannot imagine
that it is a common instruction to execute. This also is not the first time we
perform such checks; cf. udiv.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/289
I expect this is going to be tricky to get in. I ran into the following issues:
* test_ShowWindow behaves very strangely on Windows. It seems this isn't typical behavior, and is caused by an interaction with test_SetFocus, but I'm not sure exactly what it does to the thread state that causes this.
* Many of the SetWindowPos flag combinations tested don't actually show the window on Windows, therefore they don't send EVENT_SYSTEM_FOREGROUND. I was able to reproduce this with a stand-alone test, so it seems to be normal behavior.
* Windows can show a window without activating it, and Wine on X11 can't do that reliably for managed windows.
* There are a couple of cases where Windows sends an event and Wine doesn't. I figure it's OK to not cover every case, but I can go back and investigate those if needed.
This interacts with https://gitlab.winehq.org/wine/wine/-/merge_requests/2314, in that the tests don't really test much without it. I applied that MR for my own testing.
--
v3: win32u: Implement EVENT_SYSTEM_FOREGROUND.
user32: Run tests that notice focus changes early.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2853
This fixes an issue when the path includes non-ASCII characters.
Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com>
--
v4: mshtml: Call UrlUnescapeW() with URL_UNESCAPE_AS_UTF8 in is_gecko_path().
shlwapi/tests: Test UrlUnescapeW() with URL_UNESCAPE_AS_UTF8.
kernelbase: Implement URL_UNESCAPE_AS_UTF8 for UrlUnescapeW().
shlwapi/tests: Test UrlUnescapeW() with independent data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/585
DirectX's FFP normalizes the zero vector to the zero vector, but GLSL
normalizes them to all NaN.
This patch creates `ffp_normalize`, which normalizes vectors but
has DirectX's behavior on 0 vectors. Further patches in this set switch
other calls from GLSL's `normalize` to the 0-safe version.
This fixes [36564](https://bugs.winehq.org/show_bug.cgi?id=36564).
--
v3: wined3d: Use ffp_normalize in shader_glsl_ffp_vertex_lighting_footer.
wined3d: Use ffp_normalize in shader_glsl_ffp_vertex_lighting.
wined3d: Implement a zero-safe normalize function for FFP.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3419