Dropping the workarounds for Windows versions that we don't care about anymore makes it easier to understand what these tests are doing and what's going wrong when they fail.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6001
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44863
The bug has been fixed already by moving ddraw4 vertex buffers into
system memory. Changing this value makes the game create a smaller
buffer, which makes the game fast on video memory buffers. I think we
should stay close to what Windows drivers report even though we
mitigated the original issue in a different way.
--
v2: ddraw: Set dwMaxVertexCount to 2048.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5687
--
v2: win32u: Simplify the logic for driver messages polling.
win32u: Use the thread message queue shared memory in peek_message.
win32u: Allocate heap in peek_message only when necessary.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5970
> Onimusha: Warlords doesn't even use H264 and has several other problems. None of these games need H264 to be explicitly exposed, they only need compressed output.
This merge request isn't about H.264; it's about compressed samples in general. 1/3 and 2/3 are here because H.264 needs slightly special treatment.
> This is also only making my work on upstreaming Proton changes more difficult and I don't really understand what you are trying to achieve here.
The purpose of 3/3 is to fix bugs related to applications explicitly or implicitly assuming that the media source outputs compressed samples.
What changes does it make more difficult to upstream?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5988#note_75210
This is part XVI of cmd engine rewrite.
Nothing fancy, mainly setting success/failure return code
for a bunch of commands.
Some code cleanup.
--
v2: programs/cmd: Set success/failure return code for LABEL command.
programs/cmd: Set success/failure return code for VOL command.
programs/cmd: Set success/failure return code for VERIFY command.
programs/cmd: Set success/failure return code for VER command.
programs/cmd: Set success/failure return code for DATE TIME commands.
programs/cmd: Set success/failure return code for SETLOCAL/ENDLOCAL commands.
programs/cmd/tests: Test success / failure for more commands.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5997
The source reader accepts incomplete output types that decoders don't.
This is for instance the case with audio types with only a subtype but
no MF_MT_AUDIO_BITS_PER_SAMPLE attribute specified.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5989
First part of a series introducing a separate unix interface for the MF media source. The goal is to use a synchronous demuxing-only interface, similar to native, which will be simpler and faster and better fitted to most MF media source use cases.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5998
Used for winex11 and later will be used in winemac and winewayland.
--
v3: win32u: Pass the shape bitmap info and bits to window_surface flush.
win32u: Update the window surface shape with color key and alpha.
win32u: Use a 1bpp bitmap to store the window surface shape bits.
win32u: Introduce a new window surface helper to set window shape.
win32u: Pass whether window is shaped to drivers WindowPosChanging.
win32u: Pass the window surface rect for CreateLayeredWindow.
win32u: Split a new create_window_surface helper from apply_window_pos.
win32u: Move offscreen window surface creation fallback.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5962
--
v2: d3dx9: Add support for mipmap generation to D3DXCreateVolumeTextureFromFileInMemoryEx().
d3dx9: Use d3dx_image structure inside of D3DXCreateVolumeTextureFromFileInMemoryEx().
d3dx9: Cleanup texture value argument handling in D3DXCreateVolumeTextureFromFileInMemoryEx().
d3dx9: Refactor texture creation and cleanup in D3DXCreateVolumeTextureFromFileInMemoryEx().
d3dx9/tests: Add more tests for D3DXCreateVolumeTextureFromFileInMemoryEx().
d3dx9: Use shared code in D3DXLoadVolumeFromFileInMemory().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5881
Fix black screen issues for Active Trader Pro and Assetto Corsa. This reverts commit 4124478b.
For Active Trader Pro, the hack ends up clearing a context that was previously drawn to to black,
possibly because multiple OpenGL contexts are involved according to Henri's investigation.
Assetto Corsa creates a D3D device for a window but doesn't actually do any rendering with it. After
ceefcca7, having an OpenGL context for a window clears its OpenGL surface to black after its view
becomes visible. The OpenGL surface is on top of other layers for the window so the window becomes
black after that. The blackness is originally from glDrawBuffer(GL_FRONT_AND_BACK), which presumably
prepares a zero-initialized OpenGL front draw buffer. This also suggests that 4124478b is no longer
necessary. I could delay the clearToBlackIfNeeded() call so it uses the behavior before ceefcca7,
but now that it seems the hack is no longer necessary and might cause more errors. CrossOver has
disabled the hack for a while and it seems fine. I think it's time to remove the hack.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5929
Using IMF2DBuffer2_Lock2DSize with LockFlags_Write dramatically improves
performance over IMFMediaBuffer_Lock when using a DXGI buffer.
IMFMediaBuffer_Lock does not know that this buffer will not be read and
therefore performs an unnecessary transfer of the texture from GPU to CPU
before it is overwritten.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5978
As mentioned in https://gitlab.winehq.org/wine/wine/-/merge_requests/5264, the next step for OpenGL in the Wayland driver is support for WGL_ARB_pixel_format. It seems possible, at least in theory, to move a large part of the logic involved in this extension outside the drivers for common use by all of them (or ones that want to opt-in).
The goal of this RFC MR is, through experimentation and discussion/feedback, evaluate:
1. Whether making such functionality available outside the drivers (likely in an opt-in manner to begin with) is a productive way forward, or the complexity and platform specific decisions favor the current per-driver approach.
2. If we think that (1) is a worthy goal, what's the best mechanism to achieve it.
Note that the focus of this MR is currently on being a proof-of-concept, rather providing ready-for-detailed-review code (although I have done my best to keep the code decent). This MR currently (roughly in commit order):
* Introduces a new wgl driver callback to allow drivers to provide to opengl32/unix a list of formats and many details about them.
* Uses the information in that list to implement wglGetPixelFormatAttrib*.
* Uses the information in that list plus format sorting rules from WineX11 (effectively GLX rules plus tweaks) to implement wglChoosePixelFormatARB.
* Implements the get_pixel_formats callback for the Wayland driver.
* Hacks the get_pixel_formats callback for WineX11, and to allow me to run some experiments to compare the output of native WineX11 and get_pixel_formats-WineX11. In the admittedly not too many games I tried the sort order is the same, so at least that's encouraging.
My thoughts and notes so far:
* Using this approach for wglGetPixelFormatAttrib* works well, and we can also implement wglDescribePixelFormat in this way.
* It's not at all clear what the "right" sorting rules are for wglChoosePixelFormatARB.
* WineX11 uses GLX + tweaks (e.g., changes depth sorting). This means that larger formats tend to be preferred, at least according to the GLX spec. For example, asking for a r5, g6, b5 in the attributes is supposed to give back rgb888 (or even higher if available) as the top format in the list. Interestingly, and to confuse things even more, I haven't been able to make GLX return non-888(8) configs at all to actually test this more, so perhaps that's what saves it here? However, eglChooseConfig works similarly and there I was able to verify this behavior (e.g., got a nice surprise 10-bit format when asking for 5551 :)).
* Winemac has its own custom logic.
* Mesa's WGL implementation uses a different approach, closer to Wine's normal (wgl)ChoosePixelFormat, where proximity to the target format is strongly rewarded (so it seems asking for r5g6b5 is much more likely to actually get you that).
* Of course, the "gold standard" here would be to try to infer and use the rules used by some windows driver.
Looking forward to thoughts/feedback!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5388
This is part XV of cmd engine rewrite.
This MR deals with returning the proper success/failure
return code for POPD and RMDIR.
However, these commands never set ERRORLEVEL (all the
commands we've handled so far always set ERRORLEVEL in
case of failure, and some reset ERRORLEVEL in case of
successs).
So this MR on top of returning the expected success/failure
return code for these two commands, also:
- extend tests to show that ERRORLEVEL isn't set
- tweak internal call path to better handle return code
vs ERRORLEVEL.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5993
On the client side, frame aperture may be included or omitted. This can be used to include or drop the frame padding, and the VideoProcessor MFT supports it.
On GStreamer side, we can only use the unpadded frame size in the caps, because this is how decoders work, and padding needs to be added as a property of the input/output video buffers. Then, frame size needs to be adjusted to be consistent between input and output, and any difference considered as extra padding to be added on one side or the other.
--
v3: winegstreamer: Respect video format padding for input buffers too.
winegstreamer: Exclude padding from wg_format video frame size.
winegstreamer: Use video info stride in buffer meta rather than videoflip.
winegstreamer: Use a new wg_video_buffer_pool class to add buffer meta.
winegstreamer: Update the output_format when stream format changes.
winegstreamer: Pass optional GstVideoInfo to read_transform_output_data.
winegstreamer: Split read_transform_output_data in two helpers.
winegstreamer: Introduce a new sample_needs_copy_buffer helper.
winegstreamer: Introduce a new sample_set_flags_from_buffer helper.
mf/tests: Add more video processor tests with aperture.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5055
Onimusha: Warlords doesn't even use H264 and has several other problems. None of these games need H264 to be explicitly exposed, they only need compressed output.
This is also only making my work on upstreaming Proton changes more difficult and I don't really understand what you are trying to achieve here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5988#note_75084
--
v6: winegstreamer: Respect video format padding for input buffers too.
winegstreamer: Normalize video processor and color converter apertures.
winegstreamer: Normalize both input and output media types stride at once.
winegstreamer: Use video info stride in buffer meta rather than videoflip.
winegstreamer: Keep the input caps on the transform.
winegstreamer: Use a new wg_video_buffer_pool class to add buffer meta.
winegstreamer: Only use pool and set buffer meta for raw video frames.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5972
GStreamer uses _SC_NPROCESSORS_CONF to determine 'max-threads'. On the
Steam Deck, this is configured to be 16 (which is double its number
of logical cores).
_SC_NPROCESSORS_CONF also disregards a process's CPU affinity, thus it
can create more threads than is useful, which ultimately wastes memory
resources.
Using affinity to set 'max-threads' addresses both these problems.
--
v11: winegstreamer: Set 'max_threads' to 4 for 32-bit processors.
winegstreamer: Use thread_count to determine 'max-threads' value.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5923
GStreamer uses _SC_NPROCESSORS_CONF to determine 'max-threads'. On the
Steam Deck, this is configured to be 16 (which is double its number
of logical cores).
_SC_NPROCESSORS_CONF also disregards a process's CPU affinity, thus it
can create more threads than is useful, which ultimately wastes memory
resources.
Using affinity to set 'max-threads' addresses both these problems.
--
v10: winegstreamer: Set 'max_threads' to 4 for 32-bit processors.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5923
GStreamer uses _SC_NPROCESSORS_CONF to determine 'max-threads'. On the
Steam Deck, this is configured to be 16 (which is double its number
of logical cores).
_SC_NPROCESSORS_CONF also disregards a process's CPU affinity, thus it
can create more threads than is useful, which ultimately wastes memory
resources.
Using affinity to set 'max-threads' addresses both these problems.
--
v9: winegstreamer: Set MAX_THREADS to 4 for i386.
winegstreamer: Use thread_count to determine 'max-threads' value.
winegstreamer: Use process affinity to calculate thread_count.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5923
--
v5: winegstreamer: Respect video format padding for input buffers too.
winegstreamer: Normalize video processor and color converter apertures.
winegstreamer: Normalize both input and output media types stride at once.
winegstreamer: Use video info stride in buffer meta rather than videoflip.
winegstreamer: Keep the input caps on the transform.
winegstreamer: Use a new wg_video_buffer_pool class to add buffer meta.
winegstreamer: Only use pool and set buffer meta for raw video frames.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5972
GStreamer uses _SC_NPROCESSORS_CONF to determine 'max-threads'. On the
Steam Deck, this is configured to be 16 (which is double its number
of logical cores).
_SC_NPROCESSORS_CONF also disregards a process's CPU affinity, thus it
can create more threads than is useful, which ultimately wastes memory
resources.
Using affinity to set 'max-threads' addresses both these problems.
--
v8: winegstreamer: Set MAX_THREADS to 4 for i386.
winegstreamer: Use thread_count to determine 'max-threads' value.
winegstreamer: Use process affinity to calculate thread_count.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5923
--
v2: xcopy: Add support for parsing concatenated switches.
xcopy: Handle switch options concatenated with path.
xcopy: Introduce get_arg helper that duplicates first argument to new string.
xcopy: Strip quotes only from source and destination arguments.
xcopy: Exit on invalid command line argument.
xcopy: Exit after displaying help message.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5941
Fixes Ball at Work: The Ultimate Speedrun Platformer! failing to start (which receives such non-standard headers from the servers).
While testing this I found more weird aspects of handling invalid reply header names on Windows:
- leading spaces are not skipped, but if the first character is a space then two more spaces added at start of header name and then all the other invalid characters in the name (like '@' or 0xfe) are ignored (otherwise without the space at name start the presence of such header fails request); then such a header saved by failing requests can't be queried with WinHttpQueryHeaders() as the presence of invalid characters (including space) fails that with ERROR_INVALID_PARAMETER;
- trailing '\\t' are not skipped but also do not fail the request and the header with tab is present in raw headers.
But I suppose we don't need to complicate things by replicating this behaviour precisely until anything depends on that. The specific game motivating the patch only receives spaces in the end of header name which are skipped on Windows while this behaviour has some obvious logic (even if doesn't follow http standard).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5975
This is part XIV of cmd engine rewrite.
It mainly tests and sets return code for a couple of directory related
commands (CD, MKDIR/MD, PUSHD, DIR).
It's on purpose that POPD isn't included in this MR:
it will require (as RMDIR) some changes not directly related
to command itself (more on next MR).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5986
I was hoping that the new tests would provide evidence that RtlQueryRegistryValues uses RegGetValue to ensure that multi-strings are double-null-terminated. Instead the tests suggest that my hypothesis was wrong because RegGetValue only ensures single null termination, not double null termination. We should fix RegGetValue anyway for the sake of applications that expect it to null-terminate.
--
v5: kernelbase: Ensure null termination in RegGetValue[AW].
windowscodecs: Use RegQueryValueExW in ComponentInfo_GetStringValue.
twinapi.appcore: Initialize size argument to RegGetValueW.
shell32: Pass size in bytes to RegGetValueW.
msi: Initialize size argument to GetRegValueW.
mscoree: Pass size in bytes to RegGetValueW.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5969
--
v3: winegstreamer: Respect video format padding for input buffers too.
winegstreamer: Normalize the video processor media types apertures.
winegstreamer: Normalize both input and output media types stride at once.
winegstreamer: Use video info stride in buffer meta rather than videoflip.
winegstreamer: Keep the input caps on the transform.
winegstreamer: Use a new wg_video_buffer_pool class to add buffer meta.
winegstreamer: Only use pool and set buffer meta for raw video frames.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5972
--
v2: winegstreamer: Respect video format padding for input buffers too.
winegstreamer: Normalize video processor and color converter apertures.
winegstreamer: Normalize both input and output media types stride at once.
winegstreamer: Use video info stride in buffer meta rather than videoflip.
winegstreamer: Keep the input caps on the transform.
winegstreamer: Use a new wg_video_buffer_pool class to add buffer meta.
winegstreamer: Only use pool and set buffer meta for raw video frames.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5972
I was hoping that the new tests would provide evidence that RtlQueryRegistryValues uses RegGetValue to ensure that multi-strings are double-null-terminated. Instead the tests suggest that my hypothesis was wrong because RegGetValue only ensures single null termination, not double null termination. We should fix RegGetValue anyway for the sake of applications that expect it to null-terminate.
--
v4: kernelbase: Ensure null termination in RegGetValue[AW].
https://gitlab.winehq.org/wine/wine/-/merge_requests/5969
I was hoping that the new tests would provide evidence that RtlQueryRegistryValues uses RegGetValue to ensure that multi-strings are double-null-terminated. Instead the tests suggest that my hypothesis was wrong because RegGetValue only ensures single null termination, not double null termination. We should fix RegGetValue anyway for the sake of applications that expect it to null-terminate.
--
v3: kernelbase: Ensure null termination in RegGetValue[AW].
windowscodecs: Use RegQueryValueExW in ComponentInfo_GetStringValue.
advapi32/tests: Drop security test workarounds for Windows <= 2000.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5969
Used for winex11 and later will be used in winemac and winewayland.
--
v2: win32u: Pass the shape bitmap info and bits to window_surface flush.
win32u: Update the window surface shape with color key and alpha.
win32u: Use a 1bpp bitmap to store the window surface shape bits.
win32u: Introduce a new window surface helper to set window shape.
win32u: Pass whether window is shaped to drivers WindowPosChanging.
win32u: Pass the window surface rect for CreateLayeredWindow.
win32u: Split a new create_window_surface helper from apply_window_pos.
win32u: Move offscreen window surface creation fallback.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5962
This MR adds a default implementation for `wglChoosePixelFormatARB` (in opengl32.dll) which will be used automatically if the driver populates the wgl_pixel_format ARB fields. Thus winex11 automatically uses this, and this MR removes the driver internal implementation.
The second part of this MR adds `WGL_ARB_pixel_format` support for winewayland (we can move this to a separate MR, but I wanted to have another implementation to better assess the behavior).
The `wglChoosePixelFormatARB` behavior is loosely modeled after the the AMD driver as discussed in https://gitlab.winehq.org/wine/wine/-/merge_requests/5388. I tried to keep things simple to begin with, and the results I am getting in various apps/games are sensible, but please try this out so we can refine further.
--
v2: winewayland: Support WGL_ARB_pixel_format_float.
winewayland: Support WGL_ARB_pixel_format.
winex11: Remove driver wglChoosePixelFormatARB implementation.
opengl32: Add default implementation for wglChoosePixelFormatARB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5933
I was hoping that the new tests would provide evidence that RtlQueryRegistryValues uses RegGetValue to ensure that multi-strings are double-null-terminated. Instead the tests suggest that my hypothesis was wrong because RegGetValue only ensures single null termination, not double null termination. We should fix RegGetValue anyway for the sake of applications that expect it to null-terminate.
--
v2: kernelbase: Ensure null termination in RegGetValue[AW].
windowscodecs: Use RegQueryValueExW in ComponentInfo_GetStringValue.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5969
I was hoping that the new tests would provide evidence that RtlQueryRegistryValues uses RegGetValue to ensure that multi-strings are double-null-terminated. Instead the tests suggest that my hypothesis was wrong because RegGetValue only ensures single null termination, not double null termination. We should fix RegGetValue anyway for the sake of applications that expect it to null-terminate.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5969