- Wine-GitLab - list.winehq.org

[PATCH v5 0/1] MR11205: Winebus usb compatible ids
by Thomas Portal (＠OursCodeur) Aug. 21, 2026

Aug. 21, 2026

### What winebus reports the USB class compatible IDs (`USB\Class_03&SubClass_xx&Prot_y` and the two shorter forms) for USB devices, alongside the existing WINEBUS\\WINE_COMP_HID id. wineusb.sys already reports these IDs in this format for the devices it enumerates (dlls/wineusb.sys/wineusb.c, get_compatible_ids). winebus does not, so its synthesized USB-HID devices look different from a real Windows USB-HID device to any application that validates the USB parent. This makes winebus do the same. ### Why On Windows the USB parent carries these IDs and applications validate them through `CM_Get_Parent` or `SetupDi`. Wine omits them, so those applications fail. The Elgato Stream Deck app is one concrete case: it reports "no device found" for a connected Stream Deck Mini and recognises it once the IDs are present. winebus has no separate USB interface device to host the IDs. On a real stack the interface PDO from usbccgp is the HID device's parent; under winebus the IDs are reported on the HID device itself, which is the device an application reaches from the HID node. Only the hosting device differs from Windows; the IDs and their format match what wineusb already reports. ### How The interface class, subclass and protocol come from the udev usb_interface node (bInterfaceClass, bInterfaceSubClass, bInterfaceProtocol). get_compatible_ids formats them the same way wineusb.sys does, for USB devices that carry interface information, and keeps the existing ids ahead of them so driver binding is unchanged. ### Testing No automated test: winebus has no unit harness for the udev backend (the dinput HID test drives its own mock bus and never reaches this path), and the IDs derive from live sysfs values. Verified by hand: with the change the USB parent's CompatibleIds gains `USB\Class_03&SubClass_00&Prot_00` and the two shorter forms (read live from sysfs) alongside the existing WINE_COMP_HID, and the Elgato Stream Deck app then detects a connected Stream Deck Mini that it otherwise rejects. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59891 Signed-off-by: Thomas Portal portal.thomas(a)protonmail.com -- v5: winebus.sys: Report USB class compatible IDs. https://gitlab.winehq.org/wine/wine/-/merge_requests/11205

3 2

[PATCH v4 0/2] MR11205: Winebus usb compatible ids
by Thomas Portal (＠OursCodeur) Aug. 21, 2026

Aug. 21, 2026

### What winebus reports the USB class compatible IDs (`USB\Class_03&SubClass_xx&Prot_y` and the two shorter forms) for USB devices, alongside the existing WINEBUS\\WINE_COMP_HID id. wineusb.sys already reports these IDs in this format for the devices it enumerates (dlls/wineusb.sys/wineusb.c, get_compatible_ids). winebus does not, so its synthesized USB-HID devices look different from a real Windows USB-HID device to any application that validates the USB parent. This makes winebus do the same. ### Why On Windows the USB parent carries these IDs and applications validate them through `CM_Get_Parent` or `SetupDi`. Wine omits them, so those applications fail. The Elgato Stream Deck app is one concrete case: it reports "no device found" for a connected Stream Deck Mini and recognises it once the IDs are present. winebus has no separate USB interface device to host the IDs. On a real stack the interface PDO from usbccgp is the HID device's parent; under winebus the IDs are reported on the HID device itself, which is the device an application reaches from the HID node. Only the hosting device differs from Windows; the IDs and their format match what wineusb already reports. ### How The interface class, subclass and protocol come from the udev usb_interface node (bInterfaceClass, bInterfaceSubClass, bInterfaceProtocol). get_compatible_ids formats them the same way wineusb.sys does, for USB devices that carry interface information, and keeps the existing ids ahead of them so driver binding is unchanged. ### Testing No automated test: winebus has no unit harness for the udev backend (the dinput HID test drives its own mock bus and never reaches this path), and the IDs derive from live sysfs values. Verified by hand: with the change the USB parent's CompatibleIds gains `USB\Class_03&SubClass_00&Prot_00` and the two shorter forms (read live from sysfs) alongside the existing WINE_COMP_HID, and the Elgato Stream Deck app then detects a connected Stream Deck Mini that it otherwise rejects. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59891 Signed-off-by: Thomas Portal portal.thomas(a)protonmail.com -- v4: Co-authored-by: @rbernon https://gitlab.winehq.org/wine/wine/-/merge_requests/11205

3 3

[PATCH v3 0/1] MR11205: Winebus usb compatible ids
by Thomas Portal (＠OursCodeur) Aug. 21, 2026

Aug. 21, 2026

### What winebus reports the USB class compatible IDs (`USB\Class_03&SubClass_xx&Prot_y` and the two shorter forms) for USB devices, alongside the existing WINEBUS\\WINE_COMP_HID id. wineusb.sys already reports these IDs in this format for the devices it enumerates (dlls/wineusb.sys/wineusb.c, get_compatible_ids). winebus does not, so its synthesized USB-HID devices look different from a real Windows USB-HID device to any application that validates the USB parent. This makes winebus do the same. ### Why On Windows the USB parent carries these IDs and applications validate them through `CM_Get_Parent` or `SetupDi`. Wine omits them, so those applications fail. The Elgato Stream Deck app is one concrete case: it reports "no device found" for a connected Stream Deck Mini and recognises it once the IDs are present. winebus has no separate USB interface device to host the IDs. On a real stack the interface PDO from usbccgp is the HID device's parent; under winebus the IDs are reported on the HID device itself, which is the device an application reaches from the HID node. Only the hosting device differs from Windows; the IDs and their format match what wineusb already reports. ### How The interface class, subclass and protocol come from the udev usb_interface node (bInterfaceClass, bInterfaceSubClass, bInterfaceProtocol). get_compatible_ids formats them the same way wineusb.sys does, for USB devices that carry interface information, and keeps the existing ids ahead of them so driver binding is unchanged. ### Testing No automated test: winebus has no unit harness for the udev backend (the dinput HID test drives its own mock bus and never reaches this path), and the IDs derive from live sysfs values. Verified by hand: with the change the USB parent's CompatibleIds gains `USB\Class_03&SubClass_00&Prot_00` and the two shorter forms (read live from sysfs) alongside the existing WINE_COMP_HID, and the Elgato Stream Deck app then detects a connected Stream Deck Mini that it otherwise rejects. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59891 Signed-off-by: Thomas Portal portal.thomas(a)protonmail.com -- v3: winebus.sys: Report USB class compatible IDs. https://gitlab.winehq.org/wine/wine/-/merge_requests/11205

3 4

[PATCH v17 0/1] MR11398: wined3d: Support WINE_D3D_CONFIG=no_create_flags=0x800 (bug #50277)
by Stian Low (＠stianlow) Aug. 21, 2026

Aug. 21, 2026

Fix for UnityPlayer.dll calls to D3D11_CREATE_DEVICE_VIDEO_SUPPORT until supported. Forces UnityPlayer.dll software video decoding which skips all the cross-device multi-thread calls involving dxgi_resource_GetSharedHandle and d3d11_device_OpenSharedResource. https://bugs.winehq.org/show_bug.cgi?id=50277#c46 -- v17: wined3d: Support WINE_D3D_CONFIG=no_create_flags=0x800 https://gitlab.winehq.org/wine/wine/-/merge_requests/11398

2 5

[PATCH 0/2] MR11726: winex11: Allow child D3D presentation on fullscreen exclusive toplevel.
by Rémi Bernon (＠rbernon) Aug. 21, 2026

Aug. 21, 2026

While still ignoring child window clipping rules when toplevel window is presented. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60095 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60080 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11726

2 2

[PATCH 0/6] MR11725: win32u: Create textures for the FBO single sampled surfaces.
by Rémi Bernon (＠rbernon) Aug. 21, 2026

Aug. 21, 2026

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11725

2 6

[PATCH v2 0/5] MR11670: server: Implement thread input attachments refcounting.
by Rémi Bernon (＠rbernon) Aug. 21, 2026

Aug. 21, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47070 -- v2: server: Implement thread input attachments refcounting. server: Detach the parent window thread input when reparenting. server: Update focus and active windows in assign_thread_input. server: Update shared input keystate in assign_thread_input. server: Update both shared input at once in assign_thread_input. https://gitlab.winehq.org/wine/wine/-/merge_requests/11670

2 6

[PATCH v5 0/1] MR11566: tests: Fix tests that are faulty because of == vs ?: operator precedence.
by Brendan Shanks (＠bshanks) Aug. 21, 2026

Aug. 21, 2026

`==` has higher precedence than `?:`, meaning that a test like `ok(hr == (i < 4) ? S_OK : VFW_E_TYPE_NOT_ACCEPTED, ...)` is parsed as `(hr == (i < 4)) ? S_OK : VFW_E_TYPE_NOT_ACCEPTED` and not the intended `hr == ((i < 4) ? S_OK : VFW_E_TYPE_NOT_ACCEPTED)`. I discovered this when converting `wine/test.h` to use `bool` for conditions (MR coming soon), this generated warnings like: ``` ../dlls/amstream/tests/amstream.c: In function 'test_media_types': ../dlls/amstream/tests/amstream.c:3159:33: warning: '?:' using integer constants in boolean context [-Wint-in-bool-context] 3159 | ok(hr == (i < 4) ? S_OK : VFW_E_TYPE_NOT_ACCEPTED, "Got hr %#lx on ReceiveConnection for subtype %s.\n", hr, ../include/wine/test.h:388:53: note: in definition of macro 'winetest_ok' 388 | #define winetest_ok(cond, ...) (winetest_should_log(cond) ? winetest_ok_(__VA_ARGS__) : winetest_ok_(NULL)) | ^~~~ ../include/wine/test.h:129:18: note: in expansion of macro 'ok_' 129 | #define ok ok_(__FILE__, __LINE__) | ^~~ ../dlls/amstream/tests/amstream.c:3159:9: note: in expansion of macro 'ok' 3159 | ok(hr == (i < 4) ? S_OK : VFW_E_TYPE_NOT_ACCEPTED, "Got hr %#lx on ReceiveConnection for subtype %s.\n", hr, ``` -- v5: tests: Fix tests that are faulty because of == vs ?: operator precedence. https://gitlab.winehq.org/wine/wine/-/merge_requests/11566

3 3

[PATCH v4 0/4] MR11710: msvcrt: Don't inherit std fd attributes.
by Paul Gofman (＠gofman) Aug. 21, 2026

Aug. 21, 2026

-- v4: msvcrt: Also inherit WX_ATEOF and WX_READNL attributes. msvcrt: Don't update system std handles in msvcrt_init_io(). msvcrt: Initialize std handles in a loop in msvcrt_init_io(). msvcrt: Always set WX_TEXT flag when importing std handles. https://gitlab.winehq.org/wine/wine/-/merge_requests/11710

3 5

Re: [PATCH v2 0/1] MR11621: Prefer hidraw for Valve devices
by Rick Rey (＠AnAndroNerd) Aug. 21, 2026

Aug. 21, 2026

On Thu Aug 20 21:56:08 2026 +0000, Stian Low wrote: > > Neither, I run it in crossover. > Thanks for info. Good to know other common ways users may be running steam.exe. > Crossover is out of scope of my familiarity so these Codeweavers are > experts vs my wine only volunteer basis. > I don't remember coming across any steam.exe Valve controller bugs for > MacOS and found little to nothing for a quick WineHQ Bugzilla search so > this may be one of the first cases which seems surprising unless you're > using some less common Valve hardware. Currently the only way to do it is to use this 3rd party program. https://scryner.github.io/crosspuck/ the reason why they’re haven’t been any bug reports is the steam controller is hard to come by and most people don’t use them with any sort of Macs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11621#note_149492

1 0