Keyboard Layouts missing bindings for F5, F8, F9, F10, F11 and F12

[darcyparker]

My Hardware ID: dmidecode -s system-product-name: Peppy (Acer 720P). I am using https://mrchromebox.tech full rom firmware. I installed via iso and I have updated with GalliumOS Update.

I have reviewed the FAQ: https://wiki.galliumos.org/Media_keys_and_default_keybindings, and the layout definitions in /usr/share/X11/xkb/symbols/chromebook* and issues like I have reviewed closed issues like https://github.com/GalliumOS/galliumos-distro/issues/87 and https://github.com/GalliumOS/galliumos-distro/issues/202

It seems the Keyboard bindings for F5, F8, F9, F10, F11 and F12 are broken.

I am testing with

 xev | grep -A2 --line-buffered '^KeyRelease'     | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'

and I get the expected results for all of the function keys except the ones mentioned.

What am I missing? Or is this a bug?

[aceronian]

Same here. Also an ASUS, 14 cb3-431 (Edgar) with full rom firmware.

[ghost]

There is a new version of xkeyboard-config in the testing repo that changes some things around and fixes the missing mappings for F11 and F12. With that new package the only one that indeed doesn't work for me is F5, which curiously looks like it's being jacked by the window manager or something, because xev loses focus whenever I press it and regains focus whenever I let go. F5 works exactly as expected on my Manjaro laptop running Budgie with GalliumOS xkeyboard-config patches built from this PKGBUILD: https://git.drg.li/coltondrg-aur/galliumos-xkeyboard-config/

[darcyparker]

@coltondrg - Thanks. I enabled the testing repo, and can confirm F8, F9 and F10 work.

F5 doesn't work as you mentioned. And I can't figure out F11 and F12. I am trying overlay + - and overlay + = like it was on ChromeOS/Crouton. Instead I am getting XF86KbdBrightnessDown and XF86KbdBrightnessUp for F10 and F11. I have no keyboard backlight... so I think I will try using xmodmap to work around it.

Side note: Overlay + 0 is not F10 (like Overlay + 1 is F1, etc). But maybe that's intended because https://wiki.galliumos.org/Media_keys_and_default_keybindings suggests it is for keyboard back light.

[ghost]

@darcyparker What you're describing is the old behaviour. How did you enable the testing repo? Did you run GalliumOS Update and reboot afterwards? The new behaviour maps the entire number key row with overlay to F1-F12, so 0 should be F10, - and = are F11 and F12 respectively. The keyboard backlight controls are moved down to [, ], and \ for down, up, and toggle respectively, though the toggle doesn't work (but is detected as such). The wiki page is outdated and describes the old behaviour since the new xkeyboard-config/xkb-data package hasn't made it to stable yet.

Since F5 works on my Manjaro machine, I'm going to assume that it's not in fact a faulty mapping and is being grabbed by something else for some reason.

[darcyparker]

@coltondrg - ah... rebooting helped. Now I am getting all but F5. Previously I was not getting F8, F9, F10, F11 and F12... Then I did sudo galliumos-repodist --enable testing and galliumos-update... and F8, F9, and F10 started working. (An improvement). Then after rebooting I got F11 and F12. I should have tried rebooting... but assumed because I saw the improvement, that the new bindings were applied.

Its great to have these keys working. I am not that worried about F5 (I never use it). I may try Void linux later and see if F5 works like it does for your Manjaro machine. Or try Manjaro too.

Its great to get some extra years out of my old chromebook now.

[ghost]

That's weird, I can only assume F8, F9, and F10 not working were unrelated as I don't remember changing anything in relation to them and I'm pretty sure those keyboard mapping files are only loaded at boot (and possibly when explicitly changing the layout)

As I mentioned before, my Manjaro machine has the GalliumOS xkeyboard-config patches built from the PKGBUILD I linked above. If you use any other distro you're going to have to package those patches for that distro for any of this to work because the default upstream Chromebook mapping is complete trash and doesn't include any overlay or function keys at all.

[aceronian]

I've updated to the testing branch and it's mostly working but something strange is happening. When I change the keyboard layout to F keys mapped to media keys I get everything but F5, but if I change to a layout that doesn't have that I lose access to F5, F8, F9, and F10, but do have access to F11 and F12 on - and +.

[ghost]

That's very strange and lines up with the initial problem Darcy had. What happens when you run xev and press F8, F9, and F10?

[aceronian]

Pressing F1 as an example of how it's meant to look:

KeyPress event, serial 37, synthetic NO, window 0x4400001,
    root 0x14f, subw 0x0, time 1639757, (-55,303), root:(816,750),
    state 0x0, keycode 133 (keysym 0xfe78, Overlay1_Enable), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x4400001,
    root 0x14f, subw 0x0, time 1639957, (-55,303), root:(816,750),
    state 0x0, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x4400001,
    root 0x14f, subw 0x0, time 1640040, (-55,303), root:(816,750),
    state 0x0, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x4400001,
    root 0x14f, subw 0x0, time 1640290, (-55,303), root:(816,750),
    state 0x0, keycode 133 (keysym 0xfe78, Overlay1_Enable), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Clearly keycode 133 is the overlay key. Pressing F5, F8, F9 and F10 all produce this:

KeyPress event, serial 37, synthetic NO, window 0x4400001,
    root 0x14f, subw 0x0, time 1738605, (-27,349), root:(844,796),
    state 0x0, keycode 133 (keysym 0xfe78, Overlay1_Enable), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 37, synthetic NO, window 0x4400001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 37, synthetic NO, window 0x4400001,
    mode NotifyUngrab, detail NotifyAncestor

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

KeyRelease event, serial 37, synthetic NO, window 0x4400001,
    root 0x14f, subw 0x0, time 1739018, (-27,349), root:(844,796),
    state 0x0, keycode 133 (keysym 0xfe78, Overlay1_Enable), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

It seems it's unfocusing the window for some reason. Possibly because it's trying to bring up that volume GUI popup?

[ghost]

Interesting, for me only F5 produces that behaviour. I don't think it's related to the volume popup, I think the keypresses are just getting hijacked by something else so they're not making it to the intended window.

[aceronian]

Only F5 does that when F keys mapped to media keys is enabled, but then what's the point of having 2 rows of F keys?

[ghost]

That's even weirder. I'll have to do some further troubleshooting on that and see if I can reproduce it. The top row simply doesn't have enough keys, - and = are bound to F11 and F12 to make them available and the rest of that row is mapped for the sake of consistency. It's redundant but intuitive to have both rows mapped. Fwiw even if you have F keys mapped to F keys, the overlay+number row will still also be F keys, or at least should.

[darcyparker]

If it helps, I am using the option with 'right alt' as the overlay key.

And I run this snippet to swap the ctrl and search keys when XFCE starts (shouldn't be related, but I am just mentioning it in case).

if [ -z "$_capsAsCtrl" ]; then
    if [[ $(uname -a) == *galliumos* ]]; then
      #Temporarily remove control and mod4 because the keys will be remapped
      xmodmap -e "remove control = Control_L"
      xmodmap -e "remove mod4 = Super_L"
      #Assign new keycodes for Control_L and Super_L
      xmodmap -e "keycode 133 = Control_L"
      xmodmap -e "keycode 37 = Super_L"
      # Add back control and mod4
      xmodmap -e "add control = Control_L"
      xmodmap -e "add mod4 = Super_L"
      export _capsAsCtrl=1
    else if type croutonversion &>/dev/null; then
      # It is a chromebook (crouton), swap the search key and ctrl key
      # Note: This works well with the crouton 'keyboard' target
      # Credit for this snippet: http://goo.gl/O8zaBR
      xmodmap -e "keycode 133 = Control_L"
      xmodmap -e "keycode 37 = Overlay1_Enable"
      xmodmap -e "add control = Control_L"
      xmodmap -e "remove control = Overlay1_Enable"
      export _capsAsCtrl=1
    else
      #It is not chromebook. We'll just make capslock ctrl key (search key does not apply, so no swap)
      export _capsAsCtrl=1
      setxkbmap -option ctrl:nocaps
    fi
  fi
fi

[ghost]

Nani!? That's insane! Just do xfconf-query -c keyboard-layout -p "/Default/XkbOptions/Group" -s "ctrl:swap_lwin_lctl" -n

[ghost]

Go into Xfce's Keyboard Settings and remove the application shortcut for XF86Display, the [__]]] key won't open display settings anymore but F5 will work. This is very confusing and frustrating.

[darcyparker]

@coltondrg - nice. I knew there had to be a better way than the xmodmap stuff. Thanks for sharing how to do it with xfconf-query and using ctrl:swap_lwin_lctl.

Also that's awesome you figured out F5. I will try it out tonight.

[aceronian]

This is so odd. Doing your suggestion, @coltondrg, to remove the XF86Display shortcut now means all the F keys work perfectly, as long as F keys are mapped to media keys. When they're not mapped, F5 works but F8, F9, and F10 don't. Here's the weirdest part. The first time I press F8 in xev I get this:

KeyPress event, serial 34, synthetic NO, window 0x3e00001,
    root 0x14f, subw 0x0, time 531064, (-227,628), root:(644,1075),
    state 0x0, keycode 133 (keysym 0xfe78, Overlay1_Enable), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 37, synthetic NO, window 0x3e00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 37, synthetic NO, window 0x3e00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys:  4294967266 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           32  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyRelease event, serial 37, synthetic NO, window 0x3e00001,
    root 0x14f, subw 0x0, time 534622, (-227,628), root:(644,1075),
    state 0x0, keycode 133 (keysym 0xfe78, Overlay1_Enable), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Note the bizzaro number in the KeymapNotify event which looks suspiciously like an error code of -30. Every subsequent time it's 2. The first time I press F9, the bizzaro number is 79, and the first time I press F10 it's 4294967266 as well. Pressing any of the weird buttons makes it and the others report 2 afterwards. I need to restart xev each time I want to see these numbers.

[ghost]

Something is definitely weird here. I was floored when I discovered that deleting the keymap for XF86Display fixed the F5, on my Manjaro machine I have XF86Display mapped to something else and it still works fine but I haven't had time to investigate whether that's because of Budgie vs Xfce or Arch vs Ubuntu.

[Yekutiel]

This has been annoying for me recently because I'm accustomed to pressing F8, F9, and F10 to control my volume on my Acer C720. I spent an hour or so last night trying to resolve this. I'm glad I found this thread.

[Yekutiel]

I just realized I can trigger the following bash script...

#!/bin/sh
amixer -D pulse sset Master 5%-

by creating a keyboard shortcut at Keyboard -> Application Shortcuts

I set it up and it works. Henceforth I presume I'll be able to circumvent similar problems by creating bash scripts and binding them to keyboard shortcuts.

A quick note for newbies

Obviously the following can be bound to keyboard shortcuts using the above method as well...

#!/bin/sh
amixer -D pulse sset Master 5%+

and

#!/bin/sh
amixer -D pulse sset Master playback toggle

[darcyparker]

From my perspective this is resolved. Thanks @coltondrg . Shall I close this?

[ghost]

No, if I wanted it closed I would have done it myself. Thanks anyway.

[Yekutiel]

@coltondrg

Is there some way I can disable GalliumOS keybindings so that they work like those in Lubuntu (or perhaps Xubuntu, which I plan to try soon)?

I'm not sure what GalliumOS does with the F5 key, but whatever it does is causing me grief. I researched and experimented for several hours, but I doubt it's worth documenting because you are probably more familiar with how GalliumOS handles keybinding.

Be that as it may, I decided to try installing Lubuntu to see if it I were causing the problem or GalliumOS is causing the problem. It's clearly GalliumOS that is causing the problem.

The following is part of my xbindkeysrc file.

"spacefm ~/Downloads" F3

"spacefm ~/Videos" F4

"spacefm ~/Pictures" F5

"spacefm ~/Projects" F6

"'/home/y/Scripts/Mute and unmute volume'" F8

"'/home/y/Scripts/Decrease volume by 5 percent'" F9

"'/home/y/Scripts/Increase volume by 5 percent'" F10

On Lubuntu everything works as it should. On GalliumOS, even after deleting all but one of the Keyboard bindings, I can't consistently bind to F5. It does weird stuff. If you want me to copy and paste what I see in xev I will.

But frankly, if it were feasible, ideally I'd prefer to revert GalliumOS' keybindings to whatever is "standard" in Lubuntu (and I guess might be standard in Xubuntu).

xbindkeys is "a piece of cake" to use. Therefore, I'd like to use it (along with xmodmap, which I've been using for 4 or 5 years) to bind keys in GalliumOS. I don't want to try to wrestle with GalliumOS' keybinding any longer. It's been a huge time suck.

[ghost]

@Yekutiel If you just want the keyboard to be treated like it is out of the box in other Linux distributions, change the keyboard model to a standard 105-key PC keyboard, that should get the top row functioning in such a way that you can use xmodmap to rebind it to your heart's content, with the obvious drawback of losing the mappings for any keys which don't physically exist on the Chromebook's keyboard. If you want to revert to the upstream Chromebook keyboard model, well, it's obviously possible but attempting to remove xkb-data will result in dependency hell, so don't try it.

After you removed the key bindings for Xf86Display, did you reboot? I don't know what exactly causes the F5 key to misbehave, but I do know that having Xf86Display mapped to the display settings triggers it, and that once it's broken, it stays broken until you reboot even if you remove the mapping.

I think the issue is (at least partially) upstream in Xfwm because I use galliumos-xkeyboard-config on my PAINE with Manjaro Budgie and it doesn't exhibit anything resembling this behaviour. (using this PKGBUILD: https://aur.coltondrg.com/galliumos-xkeyboard-config/src/branch/master/PKGBUILD)

[ghost]

closing, mostly fixed, F5 issues duplicate #558