Under Windows and the PID specification it is possible to specify less than the full set of condition blocks. Under SDL and the Linux FF input API all condition blocks must always be specified.
The existing code does not set any values outside the specified axes. This effectively sets the strength to zero along the unspecified axes. Testing setting just one axis with the MS Sidewinder 2 under Windows, however, reveals that it sets the first axis (the X-axis) to the given parameter values and sets the other axis to full strength (this is most easily felt/tested with the spring effect).
This sets unspecified axes in the SDL and udev input backends to play at full strength to agree with Windows. It also updates joy.cpl to play condition effects along just the indicated axis too (as is done for non-condition effects).
--
v2: joycpl: Play condition effects on indicated axis too
https://gitlab.winehq.org/wine/wine/-/merge_requests/8824
Coordinates from mouse low level hook messages are not mapped the same way than WM_MOUSEMOVE or GetCursorPos. This causes problems on programs that make use of both values to calculate mouse movement, like the wine DirectInput implementation.
I'm marking this as a draft since I was not able to find a way to write a test for this. I'm able to easily reproduce it on Proton, because it creates a scaled full screen window, on Wine this doesn't happen so the coordinates are not required to be mapped to a scaled window.
Edit: I didn't realize that modesetting emulation was an experimental option! So, I was able to reproduce the bug by enabling it.
--
v3: dinput: Set per monitor aware DPI when handling WM_MOUSEMOVE.
win32u: Map raw coordinates to virtual screen in low-level hooks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8669
This is my first commit so I thought with something pretty unobjectionable. The merge request !8210 seems to have switched from pixmaps to pbuffers for bitmap rendering (although it might have been an earlier change). This flag was overlooked and is still checking for pixmap compatibility.
This caused problems with 16-bit bitmap rendering because, on my Nvidia driver, the pixmap bit is only ever set for onscreen (`DRAW_TO_WINDOW`) pixel formats. None of the 16-bit pixel formats are `DRAW_TO_WINDOW`, so that means it won't be able to find a good 16-bit pixel format. The pbuffer bit, on the other hand, is set for most offscreen formats and also more common for onscreen formats.
Notably this doesn't actually fix 16-bit bitmap rendering — it's pretty darn broken. Other changes need some more research & discussion though, I'll keep it for another day.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8860
--
v6: maintainers: Add a section for Windows.Devices.Enumeration.
windows.devices.enumeration: Create DEVPROP_FILTER_EXPRESSIONs from AQS filter strings and pass them to DevGetObjects.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8890