diff options
author | Peter Hutterer <peter.hutterer@who-t.net> | 2010-06-29 12:12:53 +1000 |
---|---|---|
committer | Peter Hutterer <peter.hutterer@who-t.net> | 2010-07-01 14:05:39 +1000 |
commit | 69ac909878ef80bb74c4a9ca4150eda66debd754 (patch) | |
tree | fa48683fa3fac7ae01d41b0b136da8f61b9c93d7 /xkb/xkbActions.c | |
parent | 09645864f5a52882eee51c801b3e610d683e7147 (diff) |
xkb: merge lockedPtrButtons state from all attached SDs.
Problem:
lockedPtrButtons keeps the state of the buttons locked by a PointerKeys button
press. Unconditionally clearing the bits may cause stuck buttons in this
sequence of events:
1. type Shift + NumLock to enable PointerKeys
2. type 0/Ins on keypad to emulate Button 1 press
→ button1 press event to client
3. press and release button 1 on physical mouse
→ button1 release event to client
Button 1 on the MD is now stuck and cannot be released.
Cause:
XKB PointerKeys button events are posted through the XTEST pointer device.
Once a press is generated, the XTEST device's button is down. The DIX merges
the button state of all attached SDs, hence the MD will have a button down
while the XTEST device has a button down.
PointerKey button events are only generated on the master device to avoid
duplicate events (see XkbFakeDeviceButton()). If the MD has the
lockedPtrButtons bit cleared by a release event on a physical device, no
such event is generated when a keyboard device triggers the PointerKey
ButtonRelease trigger. Since the event - if generated - is posted through
the XTEST pointer device, lack of a generated ButtonRelease event on the
XTEST pointer device means the button is never released, resulting in the
stuck button observed above.
Solution:
This patch merges the MD's lockedPtrButtons with the one of all attached
slave devices on release events. Thus, as long as one attached keyboard has
a lockedPtrButtons bit set, this bit is kept in the MD. Once a PointerKey
button is released on all keyboards, the matching release event is emulated
from the MD through the XTEST pointer device, thus also releasing the button
in the DIX.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Diffstat (limited to 'xkb/xkbActions.c')
-rw-r--r-- | xkb/xkbActions.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c index d1149a196..b4b839558 100644 --- a/xkb/xkbActions.c +++ b/xkb/xkbActions.c @@ -634,6 +634,14 @@ _XkbFilterPointerBtn( XkbSrvInfoPtr xkbi, } xkbi->lockedPtrButtons&= ~(1<<button); + if (IsMaster(xkbi->device)) + { + XkbMergeLockedPtrBtns(xkbi->device); + /* One SD still has lock set, don't post event */ + if ((xkbi->lockedPtrButtons & (1 << button)) != 0) + break; + } + /* fallthrough */ case XkbSA_PtrBtn: XkbFakeDeviceButton(xkbi->device, 0, button); |