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.
--
v5: winewayland: Support "UseSystemCursors" driver option.
winewayland: Use system cursor shapes when possible.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7678
On Mon Jun 30 13:14:24 2025 +0000, Vibhav Pant wrote:
> It would improve readability if `full_charge_capacity`, `capacity_now`
> and `rate_now` in `linux_battery` were instead replaced with an inline
> `union` type, something like
> ```c
> union {
> struct {
> int charge_full_uah;
> int charge_now_uah;
> int current_now_ua;
> } charge;
> struct {
> int energy_full_uwh;
> int energy_now_uwh;
> int power_now_uw;
> } energy;
> } capacity_now;
> ```
> With `power_unit` as the tag. The `fill_battery_state` code would also
> be much clearer as a result.
Hi Vibhav,
I had forgotten to ask if the changes reflected your suggestion.
Let me know if you'd prefer something else or I got something wrong. Thanks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8460#note_108509
Fixes gdiplus tests in Clang build.
When the compiler assumes non-trapping floating-point math, it may apply more aggressive optimizations. For example, in the fast path of `GdipInvertMatrix`, it may merge paired divisions into a single `divss` instruction. This can leave unused lanes whose results are ignored, but they still execute and may cause a division by zero, breaking tests that have the FP exception mask enabled.
Using `-ffp-exception-behavior=maytrap` prevents the compiler from performing such transformations.
It's a bit surprising that this flag also disables optimizations like those seen in the dmime tests, so there’s likely room for improvement on the compiler side. Regardless, relying on `round()` in tests isn't valid, as it's not available in msvcrt.dll and may depend on compiler-specific behavior.
--
v3: configure: Build PEs with -ffp-exception-behavior=maytrap.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8474