Peculiar keyboard behavior after installing Openbox WM

Support
1

I have the Gnome edition of Manjaro on a Macbook Pro 9,2.

I recently installed the Openbox window manager (v3.6.1-8) because I want to try out using a window manager instead of a full desktop environment.

My keyboard works perfectly find in my Gnome session, but behaves very strangely whenever I am in my Openbox session. Most of the keys, such as the 7 key, work fine, as indicated by the following output in xev:

KeyPress event, serial 47, synthetic NO, window 0x800001,
    root 0x3ef, subw 0x0, time 4312543, (693,666), root:(694,688),
    state 0x0, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XmbLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyRelease event, serial 47, synthetic NO, window 0x800001,
    root 0x3ef, subw 0x0, time 4312663, (693,666), root:(694,688),
    state 0x0, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

But others, such as the 8 key, produce no output in a text field. The output of xev is

KeymapNotify event, serial 47, 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   0   

FocusOut event, serial 47, synthetic NO, window 0x800001,
    mode NotifyNormal, detail NotifyNonlinear

I cannot tell whether or not my volume up/down/mute keys are working correctly. The output of xev appears normal:

KeyPress event, serial 47, synthetic NO, window 0x800001,
    root 0x3ef, subw 0x0, time 4364271, (98,551), root:(99,573),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 47, synthetic NO, window 0x800001,
    root 0x3ef, subw 0x0, time 4364343, (98,551), root:(99,573),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

but after setting the following keybindings in ~/.config/openbox/rc.xml

<keybind key="0x1008ff13">
      <action name="Execute">
        <command>amixer set Master 5%+</command>
      </action>
   </keybind>
    <keybind key="0x1008ff11">
     <action name="Execute">
        <command>amixer set Master 5%-</command>
      </action>
    </keybind>
    <keybind key="0x1008ff12">
      <action name="Execute">
        <command>amixer set Master toggle</command>
      </action>
   </keybind>

nothing happens when I press them. (Notice that I have used the hex keycodes instead of XF86AudioRaiseVolume and so on after reading this thread on the Arch forum. Using the key names doesn’t fix the issue.)

What might be causing this issue? What further diagnostics can I run?

2

Difficult to say - I have been using Openbox for years - albeit not on Apple hardware - I have never had any strange behaviour - on the contrary.

Initillay one would suspect the hardware - after all it is Apple branded - and I have hunch they don’t want any other OS on their system (apart from a parallels Windows) which is pretty annoying - after all you bought the deivce right?

Openbox adheres to alle the standards for X11 window managers so first thing is to check which keyboard type is defined for X in /etc/X11/xorg.conf.d/00-keyboard.conf.

Next step would be try setting keyboard layout manually using localectl.

Other than that - it is foggy

Ideas:

  • Gnome may be hiding some settings in dconf
    (try with dconf dump /org/gnome/ and sift through the content)
3

Thanks for the ideas. Here’s /etc/X11/xorg.conf.d/00-keyboard.conf:

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us"
EndSection

Seems normal, right? localectl status is

localectl status
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us

And here is setxkbmap -query if that’s helpful:

setxkbmap -query
rules:      evdev
model:      pc105
layout:     us

After noticing a mac-us option in localectl list-keymaps I tried localectl set-keymap mac-us (which causes VC Keymap above to update to mac-us) to no avail. I also tried setxkbmap -layout mac-us which is an error. (How can I get setxkbmap to tell me which layouts are allowed?)

Finally, the only part of dconf dump /org/gnome that looks like it might be informative is

[desktop/input-sources]
mru-sources=[('ibus', 'hangul'), ('xkb', 'us')]
per-window=false
show-all-sources=true
sources=[('xkb', 'us'), ('ibus', 'hangul')]
xkb-options=['compose:ralt']

(Hangul is Korean language input. But this issue happens even when I am not in Hangul mode, even if I kill ibus.)

4

Small update, I just installed vanilla Arch and am having the same exact problem, but only in Openbox.

5

perhaps you should use libintput enstead

6

A bit of a facepalm, but I found the issue: I had two </keyboard> tags in my Openbox rc.xml.

The diagnostic takeaway is, after editing the rc, run openbox --reconfigure from a terminal instead of from a run prompt. Then if you have a syntax error, it will print a warning instead of quietly breaking things.