Questions about the keyboard overlay

[fpp-gh]

[ In retrospect it was probably a mistake to post these in a closed issue (#138), although its topic was appropriate, so I'm adding them here in full view :-) ]

Since I upgraded to the "keyboard" target, my ARM Chromebook has become a lot more comfortable to use (I had tried to hack some Search key shortcuts with xmodmap myself, with little success).
I do have some follow-up questions about how this is done :

• was it finally implemented through xbmap ?
• in the initial xmodmap approach, why and how was the Search key remapped to Mode_switch ?
• for non US keyboards, the wiki says that "setxkbmap -layout xx" should be ran each time the chroot is restarted : on mine (xfce + raring), the layout seems to stick around, even across reboots.
  At first I thought this was because I left "save session" checked by default in the logout panel, but it works just the same with that unchecked.
• About once a day, after using some Search+ combination, I end up stuck in Caps Lock. Is there a way to get out of that mode, other than restarting xfce ?
• now I would like to define my own Search+key combos (with plain letters, to launch apps).
  What would the simplest way to go about this without breaking anything else ? xmodmap ? .xbindkeys.scm ?
  Most user-level utilities (like xfce's shortcut manager) don't recognize the Search key (Overlay1_Enable in xev) as a modifier, and by tinkering with .xbindkeys.scm I even managed to disable the functionality on F6/F7 :-)

Thanks for any tips,
fp

[dnschneid]

I saw your comment on the other bug, but was waiting for @drinkcat to chime in, since he masterminded it.

It was indeed implemented as a model overlay for xkbmap. As far as I can tell, Search was remapped to Mode_switch as it is one of the intrinsic modifiers for the keyboard mapping (along with ALT). That means you can add a keycode to xmodmap and specify the standard, +alt, +mode_switch, +alt+mode_switch and some others, without needing to deal with key combinations. There's some relation between mode_switch and AltGr, but I'm way out of my expertise here.

The setxkbmap was necessary for non-xfce chroots because gnome-session was broken and didn't support configuration and autostart programs. Xfce didn't need setxkbmap because its keyboard config works just fine. With @smibarber's gnome-session fixes, I believe the built-in keyboard config should just work in those environments as well, eliminating the need to manually call setxkbmap.

@drinkcat will need to comment on your caps lock issue and shortcut questions.

[drinkcat]

in the initial xmodmap approach, why and how was the Search key remapped to Mode_switch ?

Why? Well, Mode_switch is indeed similar to AltGr (ISO_Level3_Switch), but not the same, so that the Search key would not conflict with an eventual AltGr on the keyboard (http://www.linuxquestions.org/questions/linux-software-2/what-is-the-difference-between-mode_switch-and-iso_level3_switch-4175465999/ gives a good insight on what is going on).

How? keycode 0x85 = Mode_switch (the commits are still around in #138, have a look). Now that does not really solve your problem: if you do that now, you would lose the key mappings (unless you want to fix the xmodmap file to reintroduce all the mappings)...

One of the main reason for going from xmodmap to xkb is this:

! This one will break on non-US keyboard
keysym period = period greater Insert Insert

(the other is that mappings are not lost if you reload the keyboard configuration or change the layout)

With the xkb overlay, it is easy to add Search+. mapping to Insert, regardless of what the "." key is mapped to (on an US keyboard its period, greater, but on my keyboard it's period, colon, etc...)

for non US keyboards, the wiki says that "setxkbmap -layout xx" should be ran each time the chroot is restarted : on mine (xfce + raring), the layout seems to stick around, even across reboots.
At first I thought this was because I left "save session" checked by default in the logout panel, but it works just the same with that unchecked.

Well, even in XFCE, it still needs to be set if you leave the xfce setting as "Use system defaults" (if you set it manually, it should be fine). I'm trying to work on something that would synchronize the keyboard layouts between Chromium OS and the chroot display, but my code still has some issues.

About once a day, after using some Search+ combination, I end up stuck in Caps Lock. Is there a way to get out of that mode, other than restarting xfce ?

The only reason I see is that you may be accidentally pressing Search+Alt (which maps to Caps Lock). Note that you need to Hold Search, Press Alt, then release Search (Alt+Search will not work).

now I would like to define my own Search+key combos (with plain letters, to launch apps).
What would the simplest way to go about this without breaking anything else ? xmodmap ? .xbindkeys.scm ?
Most user-level utilities (like xfce's shortcut manager) don't recognize the Search key (Overlay1_Enable in xev) as a modifier, and by tinkering with .xbindkeys.scm I even managed to disable the functionality on F6/F7 :-)

That's the tricky part. I don't know how to do it. I have some ideas though, I'll do some experiments and get back to you.

[fpp-gh]

Many thanks to both of you for the quick and detailed answers !
And also for the "Search+Alt maps to Caps Lock" tip, now I can get out of
triggering it by accident :-)
Do let me know if you find some shortcut scheme that's compatible with the
overlay... At the very least it was a refreshing change to find that I
hadn't been overlooking something obvious :-)

[drinkcat]

At the very least it was a refreshing change to find that I hadn't been overlooking something obvious :-)

Nothing much is obvious with xkb, xmodmap, xkbcomp, xbindkeys, etc. There are 3-4 ways of accomplishing the same stuff, none of them being perfect in all aspects. The overlay thing was very clean until now, but getting those Search+letter shortcuts is a little messy...

Anyway, I hacked something to get Search+key to generate Super(mod4)+key events, for normal keys (letters, symbols, Tab, Esc...). You can try it out by replacing /usr/share/X11/xkb/symbols/chromebook by the content of http://pastebin.com/1RE1mFvA. It's then easy to map Super+key to anything you want using xbindkeys or shortcuts in your DE.

This works by bouncing Search+key to keycodes 208-253, then mapping those keycodes to send Super+key.

Now, strange things could happen if the keyboard natively generates keycodes 208 and above (nothing awfully bad, just that the key would map to Super+X instead of a XF86XX key).

In particular, I'm wondering about the Fn+key combinations on the Acer C7 and HP Pavilion: for example, on Dell keyboard, the Fn key press is not passed on to the OS, but Fn+key produces another code. Anyone around with one of those (@dnschneid maybe?), could you run this:

setxkbmap -model pc105
xev | grep KeyPress -A 2 --line-buffered | sed -n -e 's/.*keycode \([^ ]*\) .*$/\1/p'

And check that nothing >= 208 is generated no matter which key you press? (all single key, + fn+key combinations).

If there is no conflict, I'll put together a pull request.

[fpp-gh]

Nothing much is obvious with xkb, xmodmap, xkbcomp, xbindkeys, etc. There
are 3-4 ways of accomplishing the same stuff, none of them being perfect in
all aspects. The overlay thing was very clean until now, but getting those
Search+letter shortcuts is a little messy...
Anyway, I hacked something to get Search+key to generate Super(mod4)+key
events, for normal keys (letters, symbols, Tab, Esc...). You can try it out
by replacing /usr/share/X11/xkb/symbols/chromebook by the content of
http://pastebin.com/1RE1mFvA. It's then easy to map Super+key to anything
you want using xbindkeys or shortcuts in your DE.

Drinkcat, thanks for looking into it so quickly !
Indeed this stuff looks like unneeded rocket science, with Ariane5 piled
upon Shuttle piled upon Saturn piled upon Sputnik etc. :-)
I certainly wouldn't want my personal use case messing up something that's
clean and working well.
I will try out your symbol table shortly (on the way home right now).
Unfortunately I can't help with the >208 keycodes issue, as I only have the
Samsung ARM Chromebook, which has no Fn or other special keys (which is why
your work on this is such a big deal !).

[fpp-gh]

OK, status report...
I changed the file above to the pastebin's contents as advised, double-checked, restarted the chroot a few times.
The good news is that everything still works as before.
The bad news is that everything still works as before :-)
It seems the Search+letter combos are not yielding the >208 codes, just Search then letter (in xev, also xfce keyboard shortcuts and xbindkeys).
Maybe I am overlooking something ?...

[akobel]

This might or might not be relevant for the topic. On my previous machines, I configured some keyboard-specific remappings via udev's /lib/udev/keymap (e.g. that's how I fixed my old MacBook 4.1's switched tilde and less/greater keys). Compared to other methods, this has the benefit that it applies per device - if only one keyboard sends strange codes, you can fix only this keyboard and leave others alone. For the Chromebook, that's a real bummer, since no external keyboard has a search key (or, in non-ChromeOS-speak: LEFTMETA at the caps position).

Sadly, keymap does not seem to work for crouton on the Samsung Exynos:
After lib/udev/keymap input/event0 125 leftctrl 29 leftmeta (should swap search and ctrl key), the (physical) search key still sends keycode 125 (LEFTMETA), and the ctrl key keycode 29 (LEFTCTRL). However, if I try ...125 leftctrl 29 leftctrl (should be: make search an additional ctrl key), the search key does not send anything anymore, while ctrl works as before.
So, something does actually happen, but I cannot use keymap for the most simple use case of swapping keys. The issue is the same for any other pair of keys I tried. Also, it doesn't seem to work if I set any physical button to some other unused (unmapped) key.
The behaviour is also irregardless to the keyboard mode kbd_mode reports, whether raw/scancode after kbd_mode -s or mediumraw after kbd_mode -k. By the way, the default keyboard mode seems to be unknown or unspecified?!

Anybody got an idea what's going on here?

[dnschneid]

Try deleting the contents of /var/lib/xkb to force a re-compilation of the keyboard map: sudo rm /var/lib/xkb/*.xkm

[dnschneid]

@akobel: On ARM, it's Chromium OS that's accessing the hardware keyboard and passing the keycodes down to the chroot. The udev approach may work on x86-based Chromebooks, but udev isn't involved on ARM.

[fpp-gh]

@david : on my machine there is nothing in that folder, except for a README file...

[fpp-gh]

After your reply to akobel I thought maybe you meant that folder in Chrome and not chroot.
In that one there were a handful of xkm files. I deleted those and after a reboot there were a couple of new ones.
In the chroot however xev still returns the same values for Search+letter combos.

[akobel]

Ah, so there is no equivalent for setting device-specific scancode-to-keycode-mappings on ARM? What a pity... Thanks anyway, that lets me stay away from burning more time on that problem.

[dnschneid]

Since Chromium OS processes the hardware on ARM (or on x86 if you use the Xephyr target), the chroot doesn't get low enough access to do such processing. You could probably make the Chromium OS rootfs writable (which disables auto updating) and then tweak udev on the Chromium OS side, but I doubt that's something you want to do.

[drinkcat]

@fpp-gh: Sorry maybe I wasn't clear, the keycodes >208 are not sent out to xev, they are used by the overlay to generate Super+key events:

In xev, just an 'a' outputs:

state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,

Search+'a' now outputs:

state 0x40, keycode 38 (keysym 0x61, a), same_screen YES,

As you can see, the state is different: the second one corresponds to Super+a. When you type it in most applications, you will still get an 'a', but you use it for shortcuts in .xbindkeysrc.scm:
(xbindkey '(mod4 "a") "xev")

[fpp-gh]

Ouch, that mail above came out really messed up ! Rsposting it here :

Aha, my bad, thanks for spelling it out !
I finally got it working (after realizing that scheme comments in .xbindkeysrc.scm need to be ';', not '#' :-)

This setup is becoming really slick and usable, thanks to you !

A few more questions, if I may ?

• is there a safe way to reload my .xbindkeysrc.scm after changes, without restarting the entire chroot ?
• is the power button remappable this way ? It's a bit too easy to hit instead of Backspace, and it just shuts down the chroot...
• any idea why most plain letter keys work just find in xbindkeys, and others not at all ?
  For example on my French (azerty) Chromebook, Search + W and Search + P just won't bind...