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
--
v5: maintainers: Add a section for Windows.Devices.Enumeration.
windows.devices.enumeration: Create DEVPROP_FILTER_EXPRESSIONs from AQS filter strings and pass them to DevGetObjects.
windows.devices.enumeration: Support parsing AQS filters in IDeviceInformationStatics::FindAllAsyncAqsFilter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8890
--
v4: 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
--
v3: maintainers: Add a section for Windows.Devices.Enumeration.
windows.devices.enumeration: Create DEVPROP_FILTER_EXPRESSIONs from AQS filter strings and pass them to DevGetObjects.
windows.devices.enumeration: Support parsing AQS filters in IDeviceInformationStatics::FindAllAsyncAqsFilter.
windows.devices.enumeration/tests: Add tests for IDeviceInformationStatics::FindAllAsyncAqsFilter.
cfgmgr32: Always check the DEVPROP_OPERATOR_EQUALS mask while evaluating comparison filters.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8890
These changes fix two TYPE issues:
- TYPE output should terminate at a Ctrl-Z EOF character, if output is not redirected.
- TYPE redirection should function as a rudimentary file copy (bug #56381).
Tests run:
TYPE text_file_containing_embedded_ctrl_z.txt
(Output terminates at Ctrl-Z character.)
TYPE c:\windows\winhelp.exe >foo
(Issue raised in bug #56381. Foo is identical copy of winhelp.exe and not truncated at first NUL character. Test for this case was added to the automated tests.)
CHCP 65001
TYPE text_file_containing_unicode_characters.txt
(Unicode characters were output to the console.)
--
v2: cmd/tests: Add test for TYPE redirection.
cmd: Fix TYPE behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8874