On Mon Sep 30 17:37:11 2024 +0000, Rémi Bernon wrote:
I see, thanks. It would be nice if we could implement it on top of the WM_POINTER messages. Fwiw we can, and have, some pointer/touchpad tests now (see https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/dinput/tests/device8....), which can be run without any actual hardware as they are implemented using a virtual HID device. Then, although they are not exposed as an actual HID device, the X11 XI2 touch events are also routed through the same path (see https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winex11.drv/mouse.c#L...), and translated into WM_POINTER* messages, we could do the same for Wayland events.
OK, I think I now understand. That sounds like a promising avenue.
(I will note that if my messages seem confusing it's partly because I never noticed WM_POINTER* support was added to Wine. That's good news.)
For Wayland it would be trivial in theory to add WM_POINTER* events for the tablet code, and in fact it might make life easier. The tablet-v2 interface maps nicely to the WM_POINTER* API. Once we bind to the tablet-v2 manager, the compositor will stop sending wl_pointer events, but if we generate WM_POINTER* events, this should be fine, since DefWindowProc will translate them to WM_MOUSE* events, just like on Windows.
For the XI2 tablet code I think it's a little more hairy because I think enabling XI2/WinTab32 has other side-effects and it's only done as-needed.
Maybe it would be acceptable to implement graphics tablet WM_POINTER* events in winewayland first? It's a bit awkward because in that case, winex11 will implement only WinTab32 graphics tablet support, and winewayland will implement only WM_POINTER* graphics tablet support. (edit: for now, I mean.)