This is based on work done by Andrew Eikum. It has been in some form in Proton for the last 4 years.
If server's sampling rate is not 48kHz **DOOM Eternal** will try to set it 48kHz for the streams using the implemented interface. There's a whole class of audio devices that use 44.1kHz sampling rate and at least PulseAudio / PipeWire tends to inherit the value from the hardware to avoid resampling. The value can also be overridden by the user via the audio server's config files.
In such cases, if the interface is not present or stubbed, this results in **audio underruns and noticeable crackling**.
It's easy to test with pipewire-pulse:
```
$ cat /etc/pipewire/pipewire.conf.d/sample-rate.conf
context.properties = {
default.clock.rate = 41100
}
```
With PulseAudio this should be doable via setting `default-sample-rate = 41100` in `/etc/pulse/daemon.conf`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5585
I'm not completely sure about the mechanism, but I think it's simple enough to consider having that upstream now. This shows at least how we can leverage win32u surface changes to decide to switch surfaces on/off-screen and fallback to manual blitting.
Having the surfaces on-screen makes sure they are presented as efficiently as possible, having them off-screen we use GDI blit to indirectly call XCopyArea and this will be suboptimal, probably with visible tearing, but hopefully not too common.
--
v2: win32u: Use GDI blit to implement partial or other process presentation.
winex11: Return an offscreen HDC from vulkan_surface_detach.
win32u: Pass a HDC parameter to vulkan_surface_detach.
winex11: Create a window surface even when there is client window.
winex11: Also attach child client windows to their toplevel window.
win32u: Make sure vulkan windows have a pixel format selected.
win32u: Detach vulkan surfaces that aren't fully visible.
win32u: Detach vulkan surfaces that are offscreen or for another process.
win32u: Move vulkan surfaces to their new parent when reparenting.
win32u: Introduce a new vulkan offscreen surfaces list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
Reduces the time needed to write them from 20ms to 2ms and to read them from 10ms to 1ms, as well as reducing the number of wineserver requests by a lot.
--
v2: win32u: Read / write source modes as a single registry blob.
winex11: Only request display modes driver data when needed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5579
This improves performance for the game "Grounded", on a AMD Radeon RX 6700 XT,
with radv from Mesa 22.3.6. Testing was done with the "cb_access_map_w" option
enabled, which also improves performance with the game by itself.
From my testing, it's possible to raise the threshold from 2 ms up to 5 ms or
so, before the driver or GPU seems to reclock back to the lower power level.
However, this measurement is questionable for several reasons. It seems to vary
depending on the scene being rendered, and of course this will be specific to
the game and driver and GPU in question anyway. The game also has a weird
approach to vsync that seems to involve it presenting stale frames (and hence
artificially inflating the FPS), which I'm not fully sure I accounted for while
measuring. And of course, it's hard to be sure that 5 ms is actually the
threshold for how long the driver will go before powering down the GPU. In any
case, it seems better to err on the side of submitting more often, to make sure
the fix affects more drivers.
While submission isn't cheap, it seems to me that submitting every 2 ms is
unlikely to cause a bottleneck [consider that this is at most 8 (more)
submissions per frame].
The maximum of 4 concurrent periodically submitted buffers was chosen
arbitrarily. Removing the maximum altogether does not measurably affect
performance for this game either way.
Credit goes to Philip Rebohle and his work on DXVK for helping me to notice that
periodic submission might make a difference.
--
v3: wined3d: Submit command buffers after 512 draw or dispatch commands.
wined3d: Retrieve the VkCommandBuffer from wined3d_context_vk after executing RTV barriers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2724
Same bug class as https://gitlab.winehq.org/wine/wine/-/merge_requests/5550.
None of them are referenced by anything (not counting mfplat/main.c's debugstr_attr(), which names the two in mfapi.h - better debug output, yay I guess).
--
v3: include: Fix a typoed GUID
include: Fix a typoed GUID
include: Fix two typoed GUIDs
include: Fix two typoed GUIDs
include: Fix two typoed GUIDs
include: Fix a typoed GUID
include: Fix a typoed GUID
include: Fix a typoed GUID
include: Fix a typoed GUID
include: Fix a typoed GUID
https://gitlab.winehq.org/wine/wine/-/merge_requests/5559
After commit 898ab8dab19d498c17859f39a55e317ee7e367a5 wine would no longer
build on musl.
Issue is that apparently TCSETS2 isn't defined when including sys/ioctl.h.
A little digging shows that glibc goes ahead and includes asm/ioctls.h in
sys/ioctl.h, providing said macro. Musl on the other hand doesn't and relies
on bits/ioctl.h, which lacks said macro.
Since there is no mention in the manpage about the need to include asm/ioctls.h,
uncertain if that's an issue with musl or the manpage, would like some help on
that front so I can go open PRs to fix that respectively.
Signed-off-by: Fotios Valasiadis <fvalasiad(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5580
First part of Proton shared memory series. The full branch can be seen at https://gitlab.winehq.org/rbernon/wine/-/commits/mr/shared-memories.
--
v34: win32u: Use the desktop shared data for GetCursorPos.
server: Move the last cursor time to the desktop session object.
server: Move the cursor position to the desktop session object.
win32u: Open desktop shared objects from session mapping.
server: Return the desktop object info in get_thread_desktop.
server: Allocate shared session object for desktops.
win32u: Open the global session shared mapping.
include: Add ReadNoFence64 inline helpers.
server: Create a global session shared mapping.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3103
It can be substantially faster in some cases. Notepad++ (with several plugins) start up goes down from around ~1.03 sec to ~0.61 sec on my machine (with wineprefix active).
9b7669592d6f8b40976b571b70f8543777d35167 is what introduced this performance regression. I don't know why exactly, but it made my Notepad++ noticeably slower when launched from a file manager (so it's not just at wineprefix startup overhead), which is very annoying.
--
v2: win32u: Cache is_virtual_desktop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5070
--
v6: mfreadwrite/reader: Pass the device manager to the stream transforms.
winegstreamer/video_processor: Implement D3D awareness.
mf/tests: Test video processor D3D11 awareness.
mfreadwrite/tests: Add some source reader D3D11 awareness tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5459
I'm not completely sure about the mechanism, but I think it's simple enough to consider having that upstream now. This shows at least how we can leverage win32u surface changes to decide to switch surfaces on/off-screen and fallback to manual blitting.
Having the surfaces on-screen makes sure they are presented as efficiently as possible, having them off-screen we use GDI blit to indirectly call XCopyArea and this will be suboptimal, probably with visible tearing, but hopefully not too common.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man…
Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them?
--
v4: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
user32: Add tests for WM_INPUT_DEVICE_CHANGE messages
https://gitlab.winehq.org/wine/wine/-/merge_requests/2120
ObjC dictionary literals are autoreleased, meaning BitmapOutputTypeMap was released at the end of the first call to macdrv_copy_pasteboard_types. Any call after that was liable to crash, depending on whether it was overwritten. More complex objects on the clipboard (like a file copied in the Finder) seemed to trigger a crash, which manifested as explorer.exe taking 100% of CPU (since the main thread crashed, then the SEGV handler crashed because it's not a Wine thread).
Fixes a regression from bb2e02ab66c5c602d635722cf3a5820d6b366006.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5572
This appear to be introduced with commit 12f73ed9d851.
When This->stride is negative (bottom up image) it converts the multiplication to an UINT.
Thus causing the pointer to be incorrect when y > 0.
--
v2: windowscodecs: Avoid implicit cast changing value.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5568
This appear to be introduced with commit 12f73ed9d851.
When This->stride is negative (bottom up image) it converts the multiplication to an UINT.
Thus causing the pointer to be incorrect when y > 0.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5568
Trace output with PulseAudio:
```
0230:trace:mmdevapi:adjust_timing Requested duration 1000000 and period 0
0230:trace:mmdevapi:adjust_timing Device periods: 100000 default and 30000 minimum
0230:trace:mmdevapi:adjust_timing Adjusted duration 1000000 and period 100000
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5564
ucrtbase._mbsncpy_s is used by Marvel vs Capcom when trying to create multiplayer lobby.
The functions are also present in msvcrt (unlike msvcr70, msvcr71) where I didn't add it because it behaves differently: there is at least one weirdness when it doubles the number of characters to copy ('n' parameter, not buffer size). I suppose we don't need to explore and deal with this specific until something needs those functions from msvcrt.
--
v5: msvcrt: Implement _mbsncpy_s[_l]().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5547
--
v3: winex11: Remove now unnecessary surface wrapper struct.
win32u: Move thread detach from winex11.
win32u: Introduce a per-window vulkan surface list.
winewayland: Get rid of the now unnecessary surface wrapper.
win32u: Return the host surface directly from vulkan_surface_create.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5551
On Wed May 1 00:08:18 2024 +0000, Alistair Leslie-Hughes wrote:
> That's really not a solution. This was working without issues for many
> years. So, forcing our users to upgrade our product isn't always an option.
> Also, how backward compatible is that solution going to be? We still
> have users on *cough* wine 5, will it work for them?
Can you tell me what the actual use case is? I believe the bug report is about `start.exe`, which this MR should fix.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5400#note_69335
--
v9: win32u: Introduce a new add_virtual_modes helper.
winex11: Let win32u decide when to force update the display cache.
win32u: Don't force refresh the display cache on thread desktop change.
winex11: Report all sources as detached in virtual desktop mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5422
ucrtbase._mbsncpy_s is used by Marvel vs Capcom when trying to create multiplayer lobby.
The functions are also present in msvcrt (unlike msvcr70, msvcr71) where I didn't add it because it behaves differently: there is at least one weirdness when it doubles the number of characters to copy ('n' parameter, not buffer size). I suppose we don't need to explore and deal with this specific until something needs those functions from msvcrt.
--
v4: msvcrt: Implement _mbsncpy_s[_l]().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5547
--
v8: win32u: Introduce a new add_virtual_modes helper.
winex11: Let win32u decide when to force update the display cache.
win32u: Don't force refresh the display cache on thread desktop change.
winex11: Report all sources as detached in virtual desktop mode.
win32u: Set the virtual desktop display frequency to 60Hz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5422
On Wed Apr 24 13:55:44 2024 +0000, Yuxuan Shui wrote:
> Like I said, you need to call `ShellExecute( NULL, NULL, "linuxbinary.",
> "1", "C:\Temp\Application\linux", SW_SHOW);`, which is how `start.exe`
> would be doing.
That's really not a solution. This was working without issues for many years. So, forcing our users to upgrade our product isn't always an option.
Also, how backward compatible is that solution going to be? We still have users on *cough* wine 5, will it work for them?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5400#note_69293
ucrtbase._mbsncpy_s is used by Marvel vs Capcom when trying to create multiplayer lobby.
The functions are also present in msvcrt (unlike msvcr70, msvcr71) where I didn't add it because it behaves differently: there is at least one weirdness when it doubles the number of characters to copy ('n' parameter, not buffer size). I suppose we don't need to explore and deal with this specific until something needs those functions from msvcrt.
--
v3: msvcrt: Implement _mbsncpy_s[_l]().
msvcr80/tests: Fix errno access in tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5547
ucrtbase._mbsncpy_s is used by Marvel vs Capcom when trying to create multiplayer lobby.
The functions are also present in msvcrt (unlike msvcr70, msvcr71) where I didn't add it because it behaves differently: there is at least one weirdness when it doubles the number of characters to copy ('n' parameter, not buffer size). I suppose we don't need to explore and deal with this specific until something needs those functions from msvcrt.
--
v2: msvcrt: Implement _mbsncpy_s[_l]().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5547
Fix a regression from ee0aad5c, which changes the virtual desktop display frequency to that of
the host display while adding modes of 60Hz. So when the host display is not 60Hz, we might get
ChangeDisplaySettings() failures when virtual desktop is on because the target mode is not found
because of the frequency difference.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5557
--
v7: win32u: Introduce a new add_virtual_modes helper.
winex11: Let win32u decide when to force update the display cache.
win32u: Don't force refresh the display cache on thread desktop change.
winex11: Report all sources as detached in virtual desktop mode.
explorer: Only initialize display settings for attached devices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5422
--
v2: winex11: Remove now unnecessary surface wrapper struct.
win32u: Move thread detach from winex11.
win32u: Introduce a per-window vulkan surface list.
winewayland: Get rid of the now unnecessary surface wrapper.
win32u: Return the host surface directly from vulkan_surface_create.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5551
--
v5: mfreadwrite/reader: Pass the device manager to the stream transforms.
winegstreamer/video_processor: Implement D3D awareness.
mf/tests: Test video processor D3D11 awareness.
mfreadwrite/tests: Add some source reader D3D11 awareness tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5459