SDL
SDL copied to clipboard
tablet virtual mouse (aka evdev's EV_ABS) is broken
0001-evdev-scale-tablet-coords-for-mouse.patch.txt
Hello.
This patch fixes the mouse under qemu when tablet emulation is used for passing abs coords. Abs coords need to be scaled from 32767x32767 to the window resolution, see this: https://github.com/telmich/gpm/pull/23/commits/99e29cb2206d1c5a43c3035098ae1a7f434b9b8f as a reference. I am not saying my patch is the best possible solution. In particular the one may try to obtain these 32767 values from evdev, rather than to hard-code. So please either apply it or improve the way you think suits.
@icculus or @slouken to review.
Let's take a look at this for 2.0.20.
We should use EVIOCGABS to get the min and max axis values like we do for touchscreens
In SDL_udev.c I tried to identify that device with "ID_INPUT_TABLET" ID just to find out whether we need to use EVIOCGABS, but it doesn't accept that ID. I suppose some udev fix is needed to identify that device correctly before we can handle it as a tablet...
Hmm, I believe EVIOCGABS support is mandatory for ABS axes. Without that range information, it’s impossible to properly interpret the axis values.
Libevdev definitely seems to expect no failures for that ioctl on any ABS axis that is present on the device: https://github.com/freedesktop/libevdev/blob/066d9caf551b4d4662a776e3e3702918b0b8f3a7/libevdev/libevdev.c#L507-L518
Yes, but do you suggest doing EVIOCGABS when we already got EV_ABS? I supposed we need to first identify and query the device similar to SDL currently deals with touchpad, and then have the resolution handly for us in some struct.
@cgutman, is this something you'd like to get in for 2.0.22?
I had a PoC branch, but I wasn't able to get VirtualBox to cooperate to be able to test it.
We can move this to 2.0.24.
Please let me know if any testing is needed on qemu.
Hey @cgutman, is this something that will make this milestone?
I don't think so. I'm not actively working on this, so someone else is free to take it if they want it.
That code needs some fairly significant work to properly handle input from modern touchpads (which report individual fingers) and absolute pointing devices like VirtualBox's USB tablet device. It should probably be done early in the milestone to allow time to identify regressions.
Okay, bumped to the next milestone, thanks!
I haven't looked at this, but we still have an issue open in this milestone about wildly wrong relative mouse coordinates on VMware, and I'm wondering if this is the same bug.
I don't think they're related.
I cleaned up and pushed the fixes I had for the evdev code. It still needs more work to handle touchpads and absolute mice properly. Normalizing the absolute axis values and figuring out whether a device is direct or indirect might be tricky.
Right now we are just sending touch events for touchpads, which is probably not what applications are expecting to have to handle (similar to the situation we had with the Cocoa touchpads handling).