After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652359 - gnome-settings-daemon blocks Ctrl+Alt+P in Qwerty, in the presence of the Dvorak layout
gnome-settings-daemon blocks Ctrl+Alt+P in Qwerty, in the presence of the Dvo...
Status: RESOLVED DUPLICATE of bug 678001
Product: gnome-settings-daemon
Classification: Core
Component: media-keys
2.32.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2011-06-11 16:36 UTC by Chow Loong Jin
Modified: 2012-11-06 01:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chow Loong Jin 2011-06-11 16:36:23 UTC
When the Dvorak layout is configured as a usable layout, with the primary layout being Qwerty, GNOME Settings Daemon blocks Ctrl+Alt+P on Qwerty.

The reason for this behaviour is probably this:
 - Ctrl+Alt+L is the key binding for Lock screen
 - L on Dvorak shares the same key (and XKeyCode) as P on Qwerty
 - When g-s-d starts up (in Qwerty), it appears to bind on both Ctrl+Alt+L and Ctrl+Alt+P, while ignoring the incoming events on Ctrl+Alt+P.

As a result, Ctrl+Alt+P in Emacs, or any other program for that matter doesn't work. An easy workaround for Emacs is to use ^[^P to get Ctrl+Alt+P in.
Comment 1 Bastien Nocera 2011-07-01 13:09:29 UTC
Will, opinions on that one?
Comment 2 Will Thompson 2011-11-08 18:59:39 UTC
For what it's worth, I have Ctrl-Alt-S bound to “Launch Terminal”; when I am in Dvorak, Ctrl-Alt-O (the letter where S is printed) works in Emacs, and when I am in Qwerty, Ctrl-Alt-S also works in Emacs. Also, I cannot convince the control centre to bind Ctrl-Alt-anything to anything (it ignores the Ctrl…). So, I can't reproduce Loong Jin's issue.

In his situation, I think I would expect Ctrl-Alt-[key with L printed on it] to lock the screen even if he's switched to Dvorak; while in Dvorak, hitting Ctrl-Alt-[key with P on it] should be handed to Emacs as C-M-L, and while in Qwerty it should be C-M-P.

The two key binding behaviours I see day-to-day (with gb dvorak my default layout, and gb an alternative layout) are:

• I have Super+[GCR] (which correspond to UIO in QWERTY) bound to choosing workspaces. Metacity honours me hitting those physical keys even when I switch to QWERTY (where they really do mean UIO).
• Ctrl+[XCV] for Cut/Copy/Paste are always those logical letters, so the physical location of the shortcuts move around when I change keyboard layout.

I *believe* that, keyboard layout selections are per-window by default, not global. In that configuration, it makes sense for desktop-wide shortcuts to be relative to the default layout regardless of the currently-selected layout. When ‘Region & Language → Layouts → (o) Use same layout in all windows’ is chosen (as I think Dvorak users typically choose) it's a little less clear-cut, I guess.
Comment 3 Oleg Andreev 2012-06-06 20:57:15 UTC
I believe this is the same bug I'm experiencing in GNOME 3.4: I have English (default) and Russian layout. Keybindings (except ones from mutter) work only in the same layout they were entered in.
Comment 4 Rui Matos 2012-11-06 01:25:06 UTC
Going to dupe this on a newer bug, sorry. Should have searched bugzilla harder.

The problem is that g-s-d puts a grab for all keycodes which can yeld the L keysym. Since you have two layouts (on different xkb group indexes) which both have the L keysym, then g-s-d grabs both. But then, when matching to know if it should trigger, it only looks at the keysym so only one of both shortcuts work even though events for both keycodes are consumed and thus unavailable to applications.

*** This bug has been marked as a duplicate of bug 678001 ***