Broadcast `GUID_BLUETOOTH_RADIO_IN_RANGE` and `GUID_BLUETOOTH_RADIO_OUT_OF_RANGE` events (documented [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…) when remote devices are discovered and lost, respectively. For new devices, `RADIO_IN_RANGE` is only broadcasted if the device was not an initial entry enumerated during driver initialization.
--
v2: winebth.sys: Broadcast GUID_BLUETOOTH_RADIO_IN_RANGE events for newly discovered remote devices as well.
winebth.sys: Broadcast PnP event when remote devices are removed/lost.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7787
This fixes a misbehaving proton game that sets MF_XVP_PLAYBACK_MODE.
MF_XVP_PLAYBACK_MODE isn't mentioned in microsoft docs, but it's explained and used in the MIT-licensed [Windows-classic-samples](https://github.com/microsoft/Windows-classic-sampl…
Not sure if mfplat is the right place to add the tests for this since the code is in winegstreamer, but it's very similar to the existing mfplat tests and the test does not interface with winegstreamer directly.
It should be noted that on windows, ProcessOutput errors out if we provide a pSample with MF_XVP_PLAYBACK_MODE unset, wine simply ignores it.
--
v2: winegstreamer: Allow caller to allocate samples in MF_XVP_PLAYBACK_MODE.
mfplat/tests: Add test for MF_XVP_PLAYBACK_MODE.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7796
This fixes a misbehaving proton game that sets MF_XVP_PLAYBACK_MODE.
MF_XVP_PLAYBACK_MODE isn't mentioned in microsoft docs, but it's explained and used in the MIT-licensed [Windows-classic-samples](https://github.com/microsoft/Windows-classic-sampl…
Not sure if mfplat is the right place to add the tests for this since the code is in winegstreamer, but it's very similar to the existing mfplat tests and the test does not interface with winegstreamer directly.
It should be noted that on windows, ProcessOutput errors out if we provide a pSample with MF_XVP_PLAYBACK_MODE unset, wine simply ignores it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7796
This MR uses the cursor-shapes-v1 protocol to tell the compositor which system
cursor shape to use. If a shape match is not found (or cursor-shapes-v1
is not available) we fall back to setting the cursor buffer from the
Windows cursor data as before.
The second commit implements support for a "UseSystemCursors" driver option, similar
to what winex11 has. Since this is the first winewayland driver option we also introduce
all the related registry reading code.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57648
--
Side note: The registry code is a copy from winex11, and is the third copy in the
codebase (x11, mac, wayland). Perhaps it's worth introducing a common
ntuser function to perform the option reading for the drivers, something like
`NtUserGetDriverOption("X11 Driver", buffer, buffer_size, TRUE /* whether to read app specific option if present */)`.
With such a function there is the concern about each call reopening the registry, but we can see if that's actually a problem and how a different API (or some sort of caching) may help.
--
v3: winewayland: Support "UseSystemCursors" driver option.
winewayland: Use system cursor shapes when possible.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7678