remapping alt key loses keyboard shortcuts

Bug #771246 reported by Barry Warsaw
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Compiz
Confirmed
Low
Unassigned
compiz (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Binary package hint: unity

I'm running Unity on my MacBook Pro 1,1, however the default keybindings of putting Alt on Option and Super on Apple/Clover don't work for me. I swap them with a ~/.xmodmaprc file (which I will attach). This works fine for tools like the application switcher and emacs, and even unity's dock can be summoned with Super (on the alt/option key).

However, traditional Alt-<key> menu shortcuts are broken. As an example, when in the Terminal, hitting Alt-1 or Alt-2 to switch between tabs does not work. As soon as I hold down the Alt (on the apple/clover key), the cursor goes hollow but then tapping 1 or 2 does nothing. It does not switch tabs.

Revision history for this message
Barry Warsaw (barry) wrote :
Revision history for this message
Barry Warsaw (barry) wrote :

Oh also, this is exactly the same xmodmap I was using on this machine for Maverick under full effects classic desktop.

Revision history for this message
Chad A Davis (chadadavis) wrote :

I tried your xmodmaprc on a MBP6,2 with Natty and when I ran xmodmap in a console (as opposed to letting Gnome run it for me on login), it complained about removing Alt_R and Meta_R. Once I removed those, leaving:

remove mod1 = Alt_L Meta_L

 and it loaded, the keys were correctly swapped and I am able to use Alt-1 (i.e Cmd-1) to switch tabs in gnome-terminal. It might seem obvious, but did you check for xmodmap errors by running it manually first? Also, did you verify with xev that the correct keycodes are mapped to the correct symbols, as they should be? Does the non-responsive Alt problem occur in other applications besides gnome-terminal?

Revision history for this message
Barry Warsaw (barry) wrote :

That's very interesting. When I run xmodmap from the console (w/o letting Gnome run it for me), I get no errors. Note that I've been using this xmodmap file since at least Maverick without problem. To answer the last question, yes the problem occurs in all applications. I did verify with xev the correct keycodes (that's always kind of a PITA).

Now here's where things get weird.

If I remove the Alt_R and Meta_R, I get errors from xmodmap (actually from the X server), but leaving the file as is works just fine.

Even more interesting: if I do not let Gnome run it on login, but instead run it from the terminal after login, the Alt key works better, but not perfectly. Holding (the new) Alt invokes the application menu, but hitting say Alt-<letter> in terminal does not pull down any menu. This does not seem to be a system-wide problem though, as Alt-<letter> appears to work fine in Computer Janitor or Mahjongg for example. So maybe *that's* just a bug in Terminal. (I've noticed that other keyboard shortcuts aren't working in Terminal either).

But back to Unity. There's clearly a difference between letting Gnome run my xmodmaprc and running it manually after login. I can use that as a workaround for now. I'll be bringing this machine to UDS-O so if you're going to be there, perhaps we can take a look together.

Cheers.

Revision history for this message
Barry Warsaw (barry) wrote :

Oh, one other oddity. To invoke the Unity searcher, I have to hit Super twice. Hitting it once does nothing. Hitting it and holding it brings up the dock numbers after a second or two.

Revision history for this message
Chad A Davis (chadadavis) wrote :

This is odd. What does 'xmodmap -pm' say?
I'm guessing that the MBP1,1 and MBP6,2 might result in xmodmap having different keymaps. I'll take this Mac to ODS-O as well and we can compare keymaps.
See you there!

Revision history for this message
Barry Warsaw (barry) wrote :

This is just a very weird problem. It's almost definitely Unity related, since if I run classic desktop, my xmodmap will always work. Frankly I suspect a race condition because sometimes after first login with Unity, my xmodmap will work, and other times it won't -- but only partially. Here's some of what I've seen:

Log in with Unity, apply the xmodmap. Alt gets mapped to Apple/cmd for things like the switcher, and Super calls up the Unity search, but Alt-<key> doesn't bring up the menu bar in Terminal, or get mapped to meta in Emacs.

Log in with Unity, run gpointing-device-settings to fix the cursor, then run xmodmap. Now it everything works fine. (I suspect it isn't the actual running of g-d-s but the time between login and xmodmap). However, this isn't completely reproducible, because sometimes you get the above behavior.

Note that once the xmodmap is only partially applied, nothing seems to be able to make it fully applied. Also, xev is completely unhelpful because no keypress event is registered.

I think what's happening is that Unity is capturing certain keypresses before xev or the applications see it. There's a timing issue also so maybe when Unity is not quite done doing whatever magical thing it does before xmodmap gets run, it just hoses things permanently. I *think* a re-login won't fix this and you need to reboot, but I'm not positive about that either.

Revision history for this message
Chad A Davis (chadadavis) wrote :

I can now reproduce this issue. It is not specific to any hardware difference between MBP1,1 and MBP6,2. I can reproduce it when I use the (default) key to summon Unity (the Super key). I generally use Ctrl+space to summon Unity, and that is my current workaround; this allows the remapped Alt to function normally.

Changed in unity:
status: New → Confirmed
Changed in unity (Ubuntu):
status: New → Confirmed
Revision history for this message
Chad A Davis (chadadavis) wrote :

This happens when running xmodmap manually or letting Gnome run it. But I think Compiz (and Unity) loads before Gnome.

I tested this by setting Ctrl+space to summon Unity and logging in again. Then I changed the summon key to Super and my remapped Alt still functioned normally. I verified this by leaving it set to Super, logging in again, verified that Alt was broken, then ran unity --replace. Since xmodmap had already run and now Unity was running after it, the remapped keys all do what they are supposed to do.

I.e. xmodmap after Unity will keep some holds on Super. I guess that Unity installs a hook on Super before Gnome/xmodmap gets a chance to remap it.

Should this be assigned to Compiz, since Unity is not the only keymapping that Compiz manages?

(Could this have been the reason why Gnome loaded the xmodmap before anything else, so that the user-defined keyboard shortcuts would be relative to any remapped keys?)

Revision history for this message
Barry Warsaw (barry) wrote :

I had a brief discussion of this with Neil Patel after the Unity feedback session. He was aware of the issue and suggested that it's probably a bug in Compiz or possibly Gtk.

affects: unity → compiz
Changed in compiz:
importance: Undecided → Low
affects: unity (Ubuntu) → compiz (Ubuntu)
Changed in compiz (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.