Hello,
I am currently doing exploratory work towards an implementation of the WM_POINTER* suite of events and the related APIs (GetPointer* et al.) These APIs have superseded the old defacto WinTab standard and many modern applications support using them. This is very fortunate because I believe the new API maps fairly well to XInput 2 events and macOS NSEvent.
One annoying problem is writing conformance tests. Even when using EnableMouseInPointer, Windows still handles SetCursorPos et al. by sending WM_MOUSE* events. Even though wmpointer is present in Windows 8 onward, there is no practical way to simulate tablet events until Windows 10 1809, using the sparsely documented CreateSyntheticPointerDevice. I wrote a small program using this API on Windows. It does appear to be very useful for testing.
I have a "toy" implementation of CreateSyntheticPointerDevice et al. on a local fork of Wine, using the Linux uinput API. It seems to work but it was difficult to implement and it has numerous caveats:
- It requires permission changes since uinput is normally only accessible to root in most configurations. (Maybe not as big of a deal for testing? Could skip if unavailable; all that's needed is a simple chmod to get it working.)
- It does not integrate with Wine virtual desktop. This could probably not be done perfectly, it could be done approximately but would frustratingly require the uinput code to interact with the graphics driver.
- Windows will accept events at basically any cadence, but libinput/other parts of the stack stop working reliably without a stream of changes. I compensated for this in my toy implementation by running a separate thread and determining when I need to send extra events to ensure things work smoothly.
- May have additional caveats interacting with high DPI setups, particularly under Xwayland.
This makes it feel like it may not be an acceptable approach.
One alternative I can think of is implementing Wine synthetic pointers, XInput 2 event handling and macOS NSEvent handling somewhere in wineserver, as a layer above the wmpointer event dispatch implementation. On one side, this would work on pretty much any setup and could be visualized using SetCursorPos, but as a caveat it would mean the test suite would not be able to test the XInput 2 or NSEvent portions of the wmpointer implementation (and obviously it would mean the synthetic pointer API couldn't touch host applications, though this is probably a positive in most cases.)
Does anybody have any feelings as to how this should be handled?
Thanks, John Chadwick