There exist clients that disable hardware cursors, and instead draw a
software cursor during their renderloop. Such clients incorrectly cause
winewayland to enable relative pointer motion because winewayland thinks
the cursor is not visible, when it is in fact visible and just drawn by
the client instead.
Enabling relative pointer motion breaks compositors that simulate
wl_pointer from tablet tool motion. sway is one such compositor that
supports sending wl_pointer events for clients that don't understand
tablet-v2.
Fix this by not discarding absolute motion events even in the case that
relative pointer motion is active. When relative pointer was
implemented, winewayland didn't support SetCursorPos and accepting
absolute motion events would break mouselook in 3D games. However, now
it does support SetCursorPos so there should be no harm in accepting
absolute motion events as well.
This allows tablet devices to work with winewayland running badly
behaved clients that do software rendering of cursors on compositors
that do simulate wl_pointer from tablet motion, despite winewayland not
supporting tablet-v2 yet.
Signed-off-by: Gopal Prasad <llyyr.public(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9068
These invalid formats are rejected when creating WIC render targets. Otherwise, Wine may create a WIC render target with an unsupported format and in turn, will make testing IsSupported() method difficult.
--
v3: d2d1: Test creating WIC bitmap render targets.
d2d1: Reject unsupported formats when creating WIC bitmap render targets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1321
If the read ProgID only has a CurVer key and no CLSID key, it will directly return CO_E_CCLASSSTRING, causing the program to fail to continue running.
Add the key value for finding CurVer.
--
v13: combase:clsid_from_string_reg() add read of CurVer key value.
ole32:Do not zero out when not a CLSID
ole32/tests:Remove now succeeding todo_wine
https://gitlab.winehq.org/wine/wine/-/merge_requests/7539
uiLengthDrawn should represent the number of characters that have been processed.
However, the original implementation uses len (the count of displayed characters
in the current line), which is not accurate.
When text requires line breaks or special processing (such as adding an ellipsis),
the actual number of processed characters may differ from the number of displayed
characters.
When the DT_CALCRECT flag is absent, len gets decremented to 0 during the drawing loop.
Consequently, uiLengthDrawn becomes inaccurate since it relies on len's value for statistics.
--
v8: user32: Fix uiLengthDrawn calculation in DrawTextExW().
user32/tests: Add some tests for uiLengthDrawn calculation in DrawTextExW().
https://gitlab.winehq.org/wine/wine/-/merge_requests/8178