GNOME Bugzilla – Bug 125618
Locate pointer feature eats all Control_[LR] KeyPressed events
Last modified: 2012-10-08 11:46:02 UTC
Description of Problem: If the locate pointer feature is activated other applications will not receive KeyPress events for Control_L and Control_R anymore. Steps to reproduce the problem: 1. activate locate pointer feature 2. open xev and press/release Control_L/Control_R 3. KeyPress events will not be shown Actual Results: Control_[LR] KeyPress events get lost. Expected Results: Control_[LR] KeyPress events must be let through to applications. How often does this happen? always - if locate pointer is activated. Additional Information: gnome-settings-mouse.c uses XGrabKey for grabbing the Control_L and Conrol_R keys. Correct code must trap a press/release of a key without intervening key presses, while otherwise letting through the key events to applications.
*** Bug 155477 has been marked as a duplicate of this bug. ***
*** Bug 145591 has been marked as a duplicate of this bug. ***
Created attachment 34254 [details] [review] don't eat the key events this patch is used for a month in the Debian package and works fine, permission to commit ?
I'd say just go ahead if it's known to work.
*** Bug 160396 has been marked as a duplicate of this bug. ***
*** Bug 170834 has been marked as a duplicate of this bug. ***
Sergey any opinion on this change?
*** Bug 322545 has been marked as a duplicate of this bug. ***
this bug was filed in 2003 and is still not fixed? i dont get it i see a patch here thats not committed, so what is the status?
It's waiting on something knowing about xkb coding to comment
IIRC XGrabKey really intercepts the key in a very impolite manner - all other apps lose the access to it (I mean no incoming events generated). From the top of my head, I don't remember nice way of intercepting all keyboard events (so they would still be available to the apps).
*** Bug 341086 has been marked as a duplicate of this bug. ***
Ubuntu bugs about that: https://launchpad.net/distros/ubuntu/+source/control-center/+bug/9441 "Nautilus stops responding on copy-drag if 'Locate pointer' mouse feature is enabled If 'Locate pointer' mouse feature is enabled (Computer->Desktop preferences->Mouse->Cursors->Locate Pointer), and you try to copy file by Ctrl+dragging, nautilus will stop responding when you release Ctrl or left mouse button to drop copy to destination folder. This effectively disables all desktop operations and panels until nautilus is killed from console. Exact sequence to reproduce: 0) Enable 'Locate pointer' mouse feature 1) press Ctrl 2) drag file to destinaton 3) release Ctrl or left mouse button You must FIRST press Ctrl, and THEN begin to drag file - if order is reverse operation will success." https://launchpad.net/distros/ubuntu/+source/control-center/+bug/38144 ""Highlight pointer when you press control" option breaks firefox cut/copy by keyboard. Using an up-to-date dapper i368 install, when using the "Highlight pointer when you press control" option in the mouse preferences, you cannot use Ctrl-c to copy or Ctrl-x to cut a substring from the address box or the google search text box in firefox. Steps to reproduce: 1) Click on System->Preferences->Mouse->Pointers tab 2) Enable "Hilight pointer when you press control" option 3) Run firefox and enter text in the address box 4) Select a subsection of the text with cursor or shift+arrow keys 5) Press Ctrl-c or Ctrl-x Expected results: 1) The selected text should be copied or cut to the clipboard Actual Results: 1) The cursor is hilighted due to Ctrl being pressed 2.a) With Ctrl-c the whole of the text in the box is copied to the clipboard instead of just the selected part. 2.b) With Ctrl-x the whole of the text in the box is cut to the clipboard instead of just the selected part. Further observation: Text box widgets in form elements on web pages don't show the same buggy behaviour as the address box and google search box. Other applications (e.g. gedit) don't seem to show the bug. ..."
*** Bug 368499 has been marked as a duplicate of this bug. ***
The patch doesn't fix the issues I'm seeing. Even with it applied I cannot Ctrl-select files in the GTK+ file chooser, or items in the totem playlist, or mails in balsa. And other apps still don't see KeyPress and KeyRelease events for the affected keys. To fix it, we'd need a way to do non-exclusive key grabs (if possible including the ability to filter). Not sure if the X API offers something like that. At a cursory glance, it doesn't.
*** Bug 415636 has been marked as a duplicate of this bug. ***
Hi all, I'm not sure I shouln't report a new bug, since it's related but doesn't seem to be exactly the same problem as above. I'm using the "Highlight the pointer when you press Ctrl" on Ubutu Feisty, so 2.18, and I'm having problem with multiple lignes selection. For example, using synaptics (but I also have it inside Eclipse tables), I can't select multiple lines. Actually, I realized this feature was involved in this problem working on the KPhotoAlbum app: it was making completely buggy the Ctrl-MouseWheel feature to resize the thumbnails... Thanks
Hi all, Just pinging for updates on this. Any progress or patches to be tested? Thanks
*** Bug 513890 has been marked as a duplicate of this bug. ***
I believe that's fixed in gnome-settings-daemon in 2.22 (although it eats some other events, see bug 524499 and bug 523676).
Wouldn't it be simpler if gsd used XEvIE for this sort of stuff?
*** Bug 529316 has been marked as a duplicate of this bug. ***
I've enabled this for about 3 weeks and 2.22 works pretty well.
*** Bug 473343 has been marked as a duplicate of this bug. ***
*** Bug 545812 has been marked as a duplicate of this bug. ***
*** Bug 554223 has been marked as a duplicate of this bug. ***
Still broken under Ubuntu Intrepid. (GNOME 2.24.)
*** Bug 556501 has been marked as a duplicate of this bug. ***
*** Bug 558649 has been marked as a duplicate of this bug. ***
Hi, I think I've found a simple solution. What about just showing the locate-pointer window on KeyPress events? That way it would be possible to replay the event immediately and not keep the grab until the key is released. I did a few tests and they all seem to work: - synaptic (comment #17) - file chooser and totem playlist (comment #15) - nautilus drag-copy (comment #13) - rhythmbox row selection (bug 524499) I couldn't test media keys. (bug 524499)
Created attachment 128992 [details] [review] Move to KeyPress
That would be almost too easy... How does this cope with fast key repeat rates? Any objections against moving to keypress? Getting rid of all these issues would be awesome.
From a discussion on IRC about that problem: <whot> hadess: that's a problem then [that we need to show the cue on releasing Ctrl]. the proto allows you to replay an event, but for passive grabs you cant replay the release. and events you don't replay you won't see in other clients So the patch above would probably break other things... Ray mentioned that we should be able to add support for this through AccessX, and add a new event type for us to catch. Willie, opinion on this?
(In reply to comment #33) > From a discussion on IRC about that problem: > <whot> hadess: that's a problem then [that we need to show the cue on releasing > Ctrl]. the proto allows you to replay an event, but for passive grabs you cant > replay the release. and events you don't replay you won't see in other clients > > So the patch above would probably break other things... > > Ray mentioned that we should be able to add support for this through AccessX, > and add a new event type for us to catch. > > Willie, opinion on this? Eeeks. I dunno. It's been years since I've worked on XKB/AccessX. My opinion is that doing it at the AccessX level doesn't seem quite right, though. AccessX is about keyboard enhancements rather than providing signals to applications. However, I believe XKB emits events when modifiers are changed, and I don't believe you need to eat events or require windows to have focus for these events. As an example, run the xkbwatch application.
(In reply to comment #34) > Eeeks. I dunno. It's been years since I've worked on XKB/AccessX. My opinion > is that doing it at the AccessX level doesn't seem quite right, though. > AccessX is about keyboard enhancements rather than providing signals to > applications. What I meant here was that modifying AccessX to emit a new event for this purpose doesn't seem like the right thing to do.
Referring to comment 33 - I don't think there's any need to replay the release. What seems to need replaying is the sequence: <control press> <mouse button press> At least that's the issue for Nautilus, and also apparently the problem in bug 524499 (? weird keyboard...). The Firefox bug sounds like it's actually watching for the control press event, which is inevitably eaten, rather than looking at the state of the control modifier when it receives the subsequent key press. That should be fixable A) Just make firefox look at the modifiers B) at the firefox input layer by synthesizing the modifier key press if the state changes between events C) gnome-settings-daemon could maybe XSendEvent(..., InputFocus, ...) a key press event before replaying the non-matching event. I think that replaying the mouse events should be possible with modifications along the lines of: - For XGrabKey() pass GrabModeSync for pointer_mode - When we get the triggering key press, call XGrabPointer() to establish a pointer grab, then XAllowEvents with SyncBoth rather than SyncKeyboard. (Note that the key grab activation freezes pointer events, but doesn't grab the pointer - we need to grab the pointer to receive the pointer events and decide if we need to replay them.) - When we get a non-matching event, if it's a pointer event, call XAllowEvents with ReplayPointer rather than ReplayKeyboard - Ungrab the pointer when we get a non-matching event and also when we go ahead and run the locate pointer aniation. (Untested, may be slightly wrong.) As far as I can tell, the call to ReplayEvents with AsyncKeyboard is extraneous, so doesn't need modification.
*** Bug 589523 has been marked as a duplicate of this bug. ***
*** Bug 598716 has been marked as a duplicate of this bug. ***
*** Bug 591605 has been marked as a duplicate of this bug. ***
*** Bug 615083 has been marked as a duplicate of this bug. ***
*** Bug 530003 has been marked as a duplicate of this bug. ***
*** Bug 682760 has been marked as a duplicate of this bug. ***
Fixed with the patch from bug 682760.