PiBox » launcher

Might be due to two recently fixed problems

1. RM #949: If a touchscreen is identified, then the launcher keyboard was disabled.
2. RM #955: Recognized touchscreens was not working correctly.

So this needs to be retested with the updates and see if those fixes address this issue.

Still broken with those fixes. But the whole keyboard mapping problem is broken too.

In pmsui, there is src/config/etc/X11/xinitrc, which includes a test for a specific USB vendor/product pair for the FAVI keyboards. If found, then xmodmap is used to map the keys. This isn't very flexible, to say the least.

The more modern way of handling keyboards is XKB. This sets the keyboard type in the xorg.conf. There are a variety of configurations (see X.org wiki doc on XKB) that can be seen in /usr/share/X11/xkb/rules/base. And these can be changed at runtime with setxkbdmap.

So there are a couple of things to update here.

1. Add setxkbdmap to dev platform buildroot config.
2. Change pmsui's xinitrc to read a config file and run setxkbmap instead of using xmodmap and checking for usb identifiers.
3. Default to using pc104, us keyboard types, as in:

Section "InputClass" 
    Identifier "keyboard defaults" 
    MatchIsKeyboard "on" 

    Option "XkbModel" "pc104" 
    Option "XkbLayout" "us" 
    Option "XKbOptions" "" 
EndSection

But we don't do this in the xinitrc. Instead we use the setxkbdmap utility in the xinitrc in pmsui.

I think that may fix all my generic keyboard problems, though it's not international. Users can then change the config file, call it /etc/xkb.cfg, with a model/layout to use at boot time.

I need to manually try this to verify it works. I have an RPi1 running Kiosk that I can use to verify it.

Use of xkb didn't seem to help any, at least not without lots of customization. The technique used in pmsui's xinitrc is simpler, and as it turns out extensible.

That bit of code at the start that is looking specifically for FAVI usb ids should be changed to this:

# Load a keyboard file.  This might load more than one if there
# are multiple keyboards installed - be careful!
rm -f "/etc/X11/kbd/active" 
while read line; do
    usbid="$(echo ${line} | cut -f1 -d" ")" 
    kbdfile="$(echo ${line} | cut -f2 -d" ")" 
    kbd="$(lsusb | grep "${usbid}")" 
    if [ -n "${kbd}" ]
    then
        sh "/etc/X11/kbd/${kbdfile}" 
        echo "Keyboard: ${usbid} /etc/X11/kbd/${kbdfile}" >> "/etc/X11/kbd/active" 
    fi
done < /etc/X11/kbd/kbd.list

For this to work we need to add the following pieces to the dev platform (or maybe pmsui, but probably dev):

1. mkdir /etc/X11/kbd
2. new file: /etc/X11/kbd/kbd.list
3. Add to kbd.list for each supported input device
   1. <usbid pair> <filename>
4. Add to /etc/X11/kbd
   1. One file for each entry in kbd.list that contains the xmodmap's for the keys of interest (usually arrow keys)

Then I just need to run xev for each keyboard and get their keycodes for the arrow keys and create a new /etc/X11/kbd/<file> for that keyboard.

Yes, this is clumsy, but it's easy to extend for the DIY'ers and that's kinda what PiBox is all about.

One thing this doesn't do, as written: you can't plug in a keyboard after boot and have it work. The way around this problem is to make that new bit of code a shell script and tie it to mdev.conf's inputdev handling. That may or may not work. I may have to experiment with that.

Tested on Media System with all updates - works fine.
Tested on Player System - works fine.
Tested on Kiosk System - fails

All repo updates commited and pushed:

1. pibox
2. libpibox
3. piboxd
4. pmsui

The kiosk problem¶

The mdev.conf update breaks the launcher on touchscreens. The problem is that I changed the permissions on the input devices to 640 but for the touchscreen to work it needs to be 644.

Verified working on kiosk.

All code committed and pushed.

Closing issue.

Re-opening on 3.0.

After updating all component builds to the latest that seem to work, I'm able to boot to the dev system. However, no keyboards work at all.

It seems that no keyboards work at all, not even alphabetic keys. The changes for this RM were pushed to pmsui, so that doesn't help here.

Also, the changes from this RM are not quite right because the user should be able to extend these even on the overlay/squashfs builds. The way to do that is to change keyboard-fe.sh to merge /etc/X11/kbd/kbd.list with /media/mmcblk0p3/opt/etc/kbd.list and then sort and update the list under /etc/X11/kbd/kbd.list.

Also, the keyboard maps under /etc/X11/kbd/ should be extended with whatever is found in /media/mmcblk0p3/opt/etc/kbd.

It looks like eudev (which is Buildroot's stripped down udev extracted from systemd) and mdev can co-exist. All that's required is to run the S10udev init script as S09udev and leave the existing S10mdev script in place. What happens is that the udev script tries to clear the hotplug handler in the kernel, so by running the mdev init script after the udev init script mdev can install itself as the hotplug handler. Even with mdev handling hotplug events, the keyboards and mice just work under X. I'm not quite sure how udev is getting the hotplug events (probably through changes to devtmpfs) but plugging in the Sino keyboard and the various Favi-style keyboards all just work now.

What this means

1. I may be able to get rid of the special handlers for keyboards now. I know I just added them at the end of the 2.0 cycle but with eudev handling this for me I may not need it anymore.
2. I need to make sure udev is not doing anything else under the hood on kernel events. I don't think it is because there are no rules under /etc/udev/rules.d.
3. I need to use the Buildroot hack to enable eudev even though Busybox is providing mdev.

I tested this with keyboards and mice and also by plugging in a USB stick. They all worked fine. I did notice that repeatedly plugging and unplugging a keyboard would eventually stop all keyboards from working, but if I just plugged 3 keyboards in, one at a time, then they all worked including the FAVI keyboard with it's builtin mouse.

I also tested with the new mdev keyboard handler disabled and the keyboards just worked. So it looks like that isn't necessary anymore.

Side note: doing this allows the arrow keys to support history on the dev system.

Changes tested, committed and pushed for PiBox. The updates to pmsui for keyboards will need to be removed separately.

Closing this issue (again).