Re: [PATCH 1/6] server: Add server-side raw input functions definitions
On 06/14/2011 02:45 AM, Vincas Miliūnas wrote:
This is a partial raw input implementation for mouse and keyboard.
I've read in the IRC chat, that products of tools/make_request should not be included in a patch, so I left them out.
My first attempts were by leeching input events from queue_mouse_message and queue_keyboard_message functions, but I couldn't get mouse cursor movement right. Instead, I copied the way dinput receives input - by installing low level hooks and forwarding input to the server. This is just to get "try 1" out of the door. Of course, it would be better if the input feed would be server-side only.
I hit a very weird bug, where in peek_message function, info.msg.lParam was impossible to set with the proper lParam (it was correct in reply->lparam) value, instead is was overwritten by some constant. That was happening only for the messages sent by the patch using post_message. I guess the tales of server-side dragons hold some truth... If anyone wants to try to reproduce it, just recompile without the unused #include "user.h" in raw_input.c and run user32 tests.
This patch game-tested and works for Quake Live (in_mouse 2 for raw input), World of Tanks and Risen.
I'm not sure I like your approach and that AJ would like it either. Raw input is an "override" of regular messages caused by mouse/keyboard input. Wine server already receives these messages from x11drv (see __wine_send_input & co). When applications requests raw input events you need to tell wine server if it needs to send regular events, or ignore all events, and produce raw input events instead. Vitaliy.
On 06/16/2011 01:00 AM, Vitaliy Margolen wrote:
On 06/14/2011 02:45 AM, Vincas Miliūnas wrote:
This is a partial raw input implementation for mouse and keyboard.
I've read in the IRC chat, that products of tools/make_request should not be included in a patch, so I left them out. My first attempts were by leeching input events from queue_mouse_message and queue_keyboard_message functions, but I couldn't get mouse cursor movement right. Instead, I copied the way dinput receives input - by installing low level hooks and forwarding input to the server. This is just to get "try 1" out of the door. Of course, it would be better if the input feed would be server-side only. I hit a very weird bug, where in peek_message function, info.msg.lParam was impossible to set with the proper lParam (it was correct in reply->lparam) value, instead is was overwritten by some constant. That was happening only for the messages sent by the patch using post_message. I guess the tales of server-side dragons hold some truth... If anyone wants to try to reproduce it, just recompile without the unused #include "user.h" in raw_input.c and run user32 tests. This patch game-tested and works for Quake Live (in_mouse 2 for raw input), World of Tanks and Risen.
I'm not sure I like your approach and that AJ would like it either.
Raw input is an "override" of regular messages caused by mouse/keyboard input. Wine server already receives these messages from x11drv (see __wine_send_input & co).
When applications requests raw input events you need to tell wine server if it needs to send regular events, or ignore all events, and produce raw input events instead.
Vitaliy.
Yes, that's how the RIDEV_NOLEGACY device flag works. The application has an option to opt-in for it, but both means of providing input can take place in parallel. Well, the current patch is an non-invasive way to emulate raw input. It does not deal with the actual hardware devices, configuring the input subsystem, etc, like the windows version does. But the goal is to find the right answer :)
On 06/15/2011 10:37 PM, Vincas Miliūnas wrote:
On 06/16/2011 01:00 AM, Vitaliy Margolen wrote:
I'm not sure I like your approach and that AJ would like it either.
Raw input is an "override" of regular messages caused by mouse/keyboard input. Wine server already receives these messages from x11drv (see __wine_send_input& co).
When applications requests raw input events you need to tell wine server if it needs to send regular events, or ignore all events, and produce raw input events instead.
Vitaliy.
Yes, that's how the RIDEV_NOLEGACY device flag works. The application has an option to opt-in for it, but both means of providing input can take place in parallel.
Well, the current patch is an non-invasive way to emulate raw input. It does not deal with the actual hardware devices, configuring the input subsystem, etc, like the windows version does. But the goal is to find the right answer :)
I think you misunderstood what I was trying to say. You do not need to introduce another way of getting messages into wine server. It already getting hardware messages via send_hardware_message server call. As for the actual patches, you need to clean few things before they can go in: 1. Each patch should compile and don't break Wine. 2. No dead code should be added with each patch 3. In tests, reset last error to known bogus value like 0xdeadbeef. Not 0. 4. In C to split long text lines use this construct ("\n" instead of \): printf("foo" "bar"); 5. Don't use wchar_t in Wine. It's not compatible with WCHAR. Vitaliy.
On 06/16/2011 04:26 PM, Vitaliy Margolen wrote:
On 06/15/2011 10:37 PM, Vincas Miliūnas wrote:
On 06/16/2011 01:00 AM, Vitaliy Margolen wrote:
I'm not sure I like your approach and that AJ would like it either.
Raw input is an "override" of regular messages caused by mouse/keyboard input. Wine server already receives these messages from x11drv (see __wine_send_input& co).
When applications requests raw input events you need to tell wine server if it needs to send regular events, or ignore all events, and produce raw input events instead.
Vitaliy.
Yes, that's how the RIDEV_NOLEGACY device flag works. The application has an option to opt-in for it, but both means of providing input can take place in parallel.
Well, the current patch is an non-invasive way to emulate raw input. It does not deal with the actual hardware devices, configuring the input subsystem, etc, like the windows version does. But the goal is to find the right answer :)
I think you misunderstood what I was trying to say. You do not need to introduce another way of getting messages into wine server. It already getting hardware messages via send_hardware_message server call.
Yes, I am aware of that and that was my first approach, when I started writing this. I already have the code to map hw_input_t to raw input structures. The problem was incorrect mouse cursor movement, therefore I copied dinput approach with using GetCursorPos. I've learned more, thus the next objective would be to move the input feed completely into the server. So, instead of going server->client->server->client, it would be just server->client. The goal was to publish something and get feedback. Thanks for the great advices!
As for the actual patches, you need to clean few things before they can go in: 1. Each patch should compile and don't break Wine. 2. No dead code should be added with each patch 3. In tests, reset last error to known bogus value like 0xdeadbeef. Not 0. 4. In C to split long text lines use this construct ("\n" instead of \): printf("foo" "bar"); 5. Don't use wchar_t in Wine. It's not compatible with WCHAR.
Vitaliy.
participants (2)
-
Vincas Miliūnas -
Vitaliy Margolen