On Wed Jun 19 04:58:40 2024 +0000, Errno Ebadf wrote:
The input path goes like this:
- NtUserSendHardwareInput fills `struct send_hardware_input_params`
- dlls/win32u/window.c:NtUserCallHwndParam() takes data from
`send_hardware_input_params` and calls send_hardware_message()
- dlls/win32u/message.c:send_hardware_message() queues a message to
wineserver of type 'struct send_hardware_message_request'
- server/queue.c:DECL_HANDLER(send_hardware_message) wineserver receives
the send_hardware_message request and processes it (sending input to relevant windows, etc...) Just like @rbernon says it is possible to stuff data into lparam and get it all the way to wineserver. And it probably would be good to do it that way in order to avoid two server requests for every mouse move! But your changes right now do not put anything in lparam. Current proton (and old-style wine-staging patches) puts a RAWINPUT struct in lparam but the x11drv seems to *try* to support rawinput but does it in a confusing way and does not actually work.
Oops, I was wrong about lparam. It does not survive all the way to the server. The lparam in win32u/message.c:send_hardware_message() just adjusts the request to the server (which is defined in `struct send_hardware_message_request` (generated from `server/protocol.def`).
I think what @rbernon meant when they said "pass the raw values in a custom struct" would be giving extra data to win32u/message.c:send_hardware_message() via lparam in order to build the wineserver request to include unaccelerated values.
I like the idea of sending both accel and unaccel coordinates in one call to the server. All we really need extra is unaccel_x and unaccel_y (16 bits each). Is it okay to extend the hw_input_t.mouse struct? That would be simple.
(And dang, I am finding problems with my x11drv proton patches. Anyway, hopefully my braindumps help more than hurt. I would be happy to jump on IRC to chat about it if you want).