GNOME Bugzilla – Bug 457998
Mouse cursor not movable when using tablet instead of mouse
Last modified: 2007-08-15 17:39:47 UTC
Description of problem: My wife's system, a fully up2date i386 F-7 system, has a serial wacom tablet attached and no mouse. This bug may exist for some time already, because normally one just types username + password and does not use the mouse at the gdm screen. The serial tablet was configured manually in xorg.conf, as this cannot be autodetected. When X starts, the pointer can be moved fine using either the pen or the "mouse" on the tablet (for the short time there is just X and no greeter). However as soon as the greeter gets loaded the cursor jumps to the lower right corner of the screen and stays there. Using the "mouse" on the tablet, which result in relative pointer movement events being send, makes little impact. Using the pen, which sends absolute pointer events, makes the cursor jump to the location of the pen, and then immediately back to the lower right corner of the screen. I would be happy todo some debugging / code fixing on this myself, if someone can give me some pointers where to look in the gdm sources.
This does sound strange. Do you also see this problem after you log into your session, or does the problem only happen with GDM? Does it work better if you enable accessibility in GDM? I believe the dwellmouselistener plugin causes XInput devices to be treated like the main cursor.
Actually, Fedora has accessibility enabled by default, disabling this fixes this. Which makes sense as the tablet is configured to send core events as it is the only pointing device on the PC. So the dwellmouselistener plugin seems to be causing problems here, I guess it should check if an xinput device sends core events before enabling itself for this device.
Thanks for tracking down the problem. If you have any suggestions about how to update the Accessibility section of the docs to help people in a similar situation, that would be helpful. Also, I would be happy if someone wanted to improve the dwellmouselistener gesture listener to work better. At any rate, I'm glad to hear you were able to figure out how to get GDM to work for you.
(In reply to comment #3) > Thanks for tracking down the problem. If you have any suggestions about how to > update the Accessibility section of the docs to help people in a similar > situation, that would be helpful. > Updating the docs is not the answer, the desire with accessibility enabled is undesired and should be fixed. Notice that I'm not alone in getting hit by this bug, atleast another Fedora user has added a me too comment to the Fedora bug for this. > Also, I would be happy if someone wanted to improve the dwellmouselistener > gesture listener to work better. > I'm afraid I currently do not have much time to look into this.
Erm, s/desire/behavior/ (what was I thinking / trying to say ??)
dowstream report is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248752
So this dwellmouselistener thing has a few yuckinesses. 1) It calls XWarpPointer (motion->display, None, motion->root, 0, 0, 0, 0, motion->axis_data[0], motion->axis_data[1]); but axis_data isn't in screen coordinates at all. axis_data is in device coordinates, which means it will have the wrong scale factor and (maybe?) also won't be absolute coordinates at all. 2) X can already be configured to sends core events for extended input devices, so we could just assume the user (or the user's distribution) has configured their X server to do that. 3) gtk provides apis for talking to extended input devices, so it should use those instead of using libXi directly.
Ray, thanks for looking into this and identifying some issues with the code. If I remember properly, Bill Haneman added the code to support XInput style gestures and he did not want to make the code require that XInput devices be mapped to the core pointer. He seemed to feel that forcing this for GDM to work would cause problems for users who really want their XInput devices to not be mapped to the core pointer. So I think this code is to try to make GDM only map the XInput devices to the core pointer while GDM is running. However, if this code doesn't work and is causing problems for users - or if we think that users with a11y needs would always map their XInput devices to the core pointers anyway, then I'd be agreeable to changing this. We could even change the way it works and see if people complain. If so, then we could think about how to make this work better for people who really don't want to map their Xinput device to the core pointer. Thoughts? I don't have any XInput devices handy so it isn't easy for me to test this. Would Hans (the original bug reporter) be willing to test changing the code to remove the gestures_filter callback function and see if that makes GDM work better for his case?
The thing is, the only set ups where this code can work at all is in setups where the tablet is the same dimensions as the screen (expensive wacom displays, touch screens, etc). In all other cases it's going to misreact to input (because it's not scaling the tablet data right). In the cases where this module /does work/, you have to have the device send core events. it's the only configuration that makes sense (since the tablet is overlaid on top of the screne). In cases where you could conceivably not want to send core events (tablets, touch pads, that kind of thing), this code won't work at all. So, I guess what I'm saying is, I agree, we should just drop the XWarpPointer call. In the best case, it will make mouse movement look less fluid (because there is a certain amount of latency involved in reporting motion and then doing the mouse warp) and in the worst case it will cause the kinds of problems Hans encountering.
Ray, could you provide me with a patch to remove the offending code that you think will make GDM work better? I'll integrate this into the next GDM 2.19 release. Do you think we should just remove the XWarpPointer call or remove the gestures_filter filter function completely? Hans, if we do this, would you be willing to test the patch to see if it makes things work better for you? If we could get some verification that it works better with this change, I'd be more comfortable putting this patch upstream.
Created attachment 93154 [details] [review] untested patch He's an untested patch to get rid of the warping and other extended device handling. Since we've decided to only accept gestures from devices that send core events, we shouldn't need any extended device handling at all.
If Hans, wants to test the above patch, I've built it into rawhide. It's also available here: http://koji.fedoraproject.org/koji/buildinfo?buildID=12970
feedback?
(In reply to comment #13) > feedback? > The tablet is on my wife's pc. I just tried upgrading her gdm to rawhide (and glibc as that was needed) but after that it just hangs when trying to log in, it seems the greeter never completes loading. Probably it needs a newer something on which no explicit requires for the newer version is present. But I'm not going to upgrade my wife's machine to rawhide. So there is not much I can do atm. Ray, you could ask the other person having this problem in the Fedora bug.
If you like, I could provide Fedora 7 packages
(In reply to comment #15) > If you like, I could provide Fedora 7 packages > If thats not to much work a scratch koji build for me to pull an F-7 compatible package from would enable me to test this. Or we can wait and see what Gian's testing results in (another Fedora user with the same problem). Either way is fine with me.
http://koji.fedoraproject.org/koji/taskinfo?taskID
(In reply to comment #17) > http://koji.fedoraproject.org/koji/taskinfo?taskID > Erm, that looks like an incomplete link, and I cannot find a gdm build from around that date (probably because it was a scratch build)
woops, sorry: http://koji.fedoraproject.org/koji/taskinfo?taskID=96897
(In reply to comment #19) > woops, sorry: > http://koji.fedoraproject.org/koji/taskinfo?taskID=96897 > Thanks, I can confirm that this build fixes the problem.
Thanks for testing. I put this patch upstream so future versions of GDM should work better for you and other users with tablets.