July 2025 - Wine-gitlab - list.winehq.org

Re: [PATCH v47 0/6] MR6766: wintypes: Add stubs for Windows.Foundation.Collections.PropertySet. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6766

1 0

Re: [PATCH v5 0/4] MR8554: windows.media: Implement IActivationFactory::ActivateInstance() for IMediaTranscoder. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8554

1 0

Re: [PATCH v2 0/1] MR8673: win32u: Also flush the GL drawable if the client surface is offscreen. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8673

1 0

Re: [PATCH v2 0/1] MR8675: tools/winedump: Fix crash while dumping CLR blob:s. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8675

1 0

Re: [PATCH v2 0/1] MR8676: shell32: Add AccountPictures known folder. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8676

1 0

Re: [PATCH v2 0/2] MR8677: opengl32: Use generated header wrapper declarations. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8677

1 0

Re: [PATCH v2 0/1] MR8678: opengl32: Map glCompressedTexImage2DARB to glCompressedTexImage2D. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8678

1 0

Re: [PATCH v3 0/1] MR8659: ntdll: Ensure %cs is correct in sigcontext on x86_64 macOS. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8659

1 0

Re: [PATCH v2 0/1] MR8683: msado15/tests: Fixup error return values for the ConnectionPoint tests. - approved
by Alexandre Julliard (＠julliard) 31 Jul '25

31 Jul '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8683

1 0

[PATCH 0/1] MR8667: winebus.sys: VID 3344 devices now are catch-all hidraw for compatability.
by Ty (＠chaos) 31 Jul '25

31 Jul '25

_**Summary:**_ - changes hidraw handling for VID 3344 devices to a catch-all, ensuring the multitude (36+ devices) of virpil(vpc) devices with nearly infinitely variable parameters are all supported. _**Reason for code departing existing standards:**_ - Virpil (vpc) devices all require hidraw, vpc has never expressed interest in making a device that does not, and the devices have user defined: button counts (0-128), axis counts (0-8), PID (mandatory for user to change in case of twin-stick or twin control panels), and device descriptions. default PID is dependant on revision of device or first-firmware-installed. Because of how custom each users device is, indexing them from anything apart from VID will inherently miss some(often many) devices, breaking support. - Unfortunately, the cat is well and truly out of the bag already for virpil, so fixing the PID issues by way of virpil releasing firmware changes is not practical (forcing PID changes from virpil would reset keybinds for ~10k-100k windows and linux users in many of their games). _**Possible (theoretical) flaw with the approach:**_ - Leaguer Microelectronics (LME) shares a VID with Virpil (VPC). If any devices exist outside of virpil (say, a bootleg xinput controller off aliexpress that chose a random vid and landed on 3344), they may be adversely affected and need explicit exemption else the end user would need to set them similarly to how virpil users need to modify their kit today. LME is primarily an IoT company so should not cause any issues, but it is possible. similarly, if VPC ever released a gamepad controller (xinput) it would also have issues. VPC has never expressed interest in doing this however, so this fix should be safe forever for VPC. LME being IoT should be fairly safe, but it is something to watch for. _**The fix for the theoretical flaw:**_ - should this show up as a real issue, explicit exemption from this catch-all via an if-else or switch statement for adversely affected devices should be done. _**Closing:**_ - If there are any questions / comments, I am happy to discuss it. After long thought, ~2 years of talk on proton issues, this seems to be the logical best solution for a fix given the specific situation. In the interest of keeping this some-what light reading for a laughably small code change, I will spare the minutia of the technical details for the hardware. Hopefully this merge request should provide adequate information to any maintainer looking at why this code is the way it is, some decade down the line. Have a nice day. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8667

3 5