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...

[picostove]

@drinkcat the HP Pavilion generates keycode 246 for Fn + F13, used for toggling wifi in Chromium OS. I wasn't able to get a hold of an Acer C7 but it looks like it also has a wifi toggle (Fn + F11). As far as I can tell that's the only keycode >= 208 on either machine.

[fpp-gh]

Okay, so it seems that "killall -HUP xbindkeys" (AND then moving the mouse around :-) reloads my own bindings without disturbing those loaded in /etc/crouton. The non-working keys were mostly a combination of bad reloading of xbindkeys, and/or my lack of understanding of what commands can be passed as key bindings (like non-GUI apps). To be sure I made a test config file that binds each letter key to a zenity popup, then tried them all. Actually there is only ONE key which does not respond to the Search modifier : the "M", which is often a problem on azerty keyboards due to its placement. I will just not use it :-) So that's two of the three questions above answered, and thanks again for the great job on this !

[drinkcat]

@fpp-gh:

is there a safe way to reload my .xbindkeysrc.scm after changes, without restarting the entire chroot ?

Your mileage may vary with killall -HUP (I've had issues). Another way that is normally more reliable:

pkill xbindkeys
METHOD="xephyr" xbindkeys -fg /etc/crouton/xbindkeysrc.scm

(you can add -n to xbindkeys if you want to debug your configuration, and replace xephyr by x11 on x86)

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...

The power button does not show any event in xev, maybe the key is caught at an earlier stage by the Chrome OS X server. I'm surprised that it shuts down the chroot. On my Chromebook ARM, it locks Chrome OS if you press it long enough (2-3 seconds?), but leaves the chroot be (you only notice it got locked when you switch back to Chrome OS).

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...

They are probably caught by the DE. I know that XFCE binds Search+P by default.

[drinkcat]

@smibarber: Thanks for trying it out. I will skip that code.

[fpp-gh]

drinkcat, thanks much for the reloading method, it seems to work better indeed. I had been randomly losing keys from /etc/crouton/xbindkeysrc.scm and having flaky refreshes, no more.

Now even Search+M is responding, go figure :-) (also many of the symbol keys).

As for the power button, for now I solved it by setting the action to "None" in the XFCE settings, to avoid accidents. This is what it now returns in xev, dunno if it's usable in any way :

FocusOut event, serial 34, synthetic NO, window 0x3800001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 34, synthetic NO, window 0x3800001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 34, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   32 

[dnschneid]

Nope, that's not usable, unfortunately.

[dnschneid]

@drinkcat, did anything come of this? #362 is related.

[jkurei]

The keyboard is the biggest issue I have with my Samsung chromebook. I need a Supr_L key for my window manager, but I also need Delete/End/Start/AvPag/RePag to edit text without going mad.

I don't really need the brightness/volume combinations: how can I get that part of the keyboard target functionality without loosing Super_L?

Thanks for any tip

PD: Not sure if it is good etiquette to reuse this question for this; please tell me so if not and I'll open a new one.

[drinkcat]

@jesusiniesta : What you are looking for is mentionned in #362. This is a quite common question so I wrote a paragraph in the wiki (https://github.com/dnschneid/crouton/wiki/Keyboard#super_l-key). Feel free to modify/expand it.

[jkurei]

@drinkcat it sounds familiar to me, I probably did try something similar last time. i'll give it a try again, thanks a lot!

[dnschneid]

note to self: stop closing this until @drinkcat says so

[drinkcat]

In short, there are still 3 outstanding issues with the keyboard map:

1. We'd like to be able to bind Search+letter to custom shortcuts (I provided a solution in this thread, but it's not as clean as I'd like, so I'm not sure we want this as default behaviour).
2. We are able to swap Search key with another key (see wiki), but NOT Super_R, for some unknown reason.
3. Alt+Search should also mean Caps Lock (not only Search+Alt)

Solutions:

1. It might remain a custom modification, but we can't access overlays with xmodmap, so it won't be that easy.
2. There is some xkb weirdness happening here (Xephyr-related?). I have no idea how to go about it.
3. I think it is an easy fix.

[infamouswhiteknight]

I can't get the keyboard target to work on my chroot (saucy, KDE, samsung arm). When I try to upgrade the chroot with this target (using the command: sudo sh -e ~/Downloads/crouton -n saucy -t keyboard -u), it fails and ends with the following:

W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/Release Unable to find expected entry 'main/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file).

Anybody know what this means/why this might happen/how to fix it?

Thanks!

[drinkcat]

@infamouswhiteknight This has nothing to do with the keyboard target: It looks like you managed to install some Chrome repositories. Could you open another issue so that we can keep track of your problem better?

[infamouswhiteknight]

Oops, sorry. I could open the other issue, but now that you point out that it's about a chrome repository, I just removed it, and now updating the chroot works, as does the keyboard. Don't I feel silly. Thanks!

[dnschneid]

What should we do about this?

[drinkcat]

I should at least fix point 3 above. And leave the rest as wiki entries.

[rumly111]

I found this very useful. It is also possible to change Mod4 to Control (https://pastebin.com/e68xg2mG). Very useful for Emacs users ^_^