GNOME Bugzilla – Bug 142834
need new gesture listener for XInput valuator events which don't drive core pointer
Last modified: 2005-02-14 22:23:00 UTC
The current "dwell" mouse gesture listener doesn't listen to XKB valuator events, and even if it did, it wouldn't work since the listener relies on location of the core pointer with respect to a dialog window. The problem is, XInput valuators, when not connected to the core pointer, have an undefined relationship to the screen coordinate system; furthermore, different users have different ranges of motion. Therefore a gesture listener is required which not only listens to non-corepointer XInput valuator events, but which also uses a heuristic which allows users with varying ranges of motion to successfully execute the gesture. This means that the gesture can't be based on an absolute range of motion, or even a fixed-size range of motion, but instead must be based on things like min/max values and reversals of "slope", etc.
escalating login-stopper bug priorities.
Should I close prior bug #125428 as a duplicate? It is a little more general so I'm not sure...
no, 125428 concerns GOK, but this bug is against gdm. Possibly 125428 should be dup'ed against the 'action/input-method' command-line bugs.
*** Bug 125428 has been marked as a duplicate of this bug. ***
on second thought you are right David. I didn't see 125428 at all, since it didn't have the 'accessibility' keyword and didn't CC gnome-access-bugs. (note that the new bugzilla won't keep keywords that are added with the initial bug report, you have to add them on a subsequent edit. I filed a bugzilla bug against bugzilla, regarding that issue ;-) )
I've got a (temporary) patch that allows non-corepointer XInput devices to be used to complete pointer-based gestures, using dwellmouselistener. It's a bit of a hack, since it warps the corepointer when non-corepointer XInput events are received. However, in the use case scenario where GOK is needed by the end-user, the XInput valuators aren't normally SendCore (this would cause a conflict), so what the patch does basically is make the extended input devices act "more like the usual default" until a specific gesture has been recognized, at which time the warp/latch behavior stops. This solves several problems expediently : * Users of non-core-pointer dwell devices (e.g. head pointers) will be able to see visual feedback from their pointer motions; * The existing dwell gestures, which require not only onscreen visual indication outside the gdm login window, but also enter/exit notify events, can be completed with non-corepointer devices; * once the gesture is complete, the extended input device no longer interferes with the core pointer, thus GOK or another input-device-driven assistive technology can function without "core pointer" conflicts. (though the "best" long-term fix will be a smarter patch which treats extended input valuators differently, doing on-the-fly calibration and generally matching to the user's needs more intelligently)...
Created attachment 28529 [details] [review] patch which substantially satisfies the problem in this bug, and in bug 142833.
Bill, is this patch going in soon?
Ask George :-)
George, I think this bug needs to be addressed. Are you comfortable with Bill's patch?
Created attachment 30514 [details] [review] improved patch which allows switch, mousebutton, and key gestures
ouch, the second patch dropped the changes to dwellmouselistener.c. So I need to update the patch to include both changes.
Created attachment 30935 [details] [review] patch combining two patches above (dwell + key)
Setting GNOME milestone to 2.8.0. I'm going to ping George via email about this and a couple other gdm a11y bugs/patches.
Awaiting to confirm fix in JDS Rel3 Build 17.
John: fix missed 17, should be in nightlies and b18.
Punting to 2.8.x
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Patch applied to CVS head.