Keybow attached to Pi 4 needs another keyboard attached to function

Question

Keybow attached to Pi 4 needs another keyboard attached to function

wildestpixel opened this issue 5 years ago · comments

As the title states - been using a keybow on Pi4 for a while with another keyboard attached via a Logitech unifying receiver - all is good.

However if I detach the unifying receiver and reboot the pi, the keybow ceases to work - latest fully updated buster image.

Thinking of moving my setup to a 3a+ which has only one USB port this isn’t going to go well if its not going to work by itself (I don’t need a standard keyboard - keybow literally sends mpd commands and calls scripts for me)

Any help in getting keybow identified and working by pi as a solus device ?

Philip Howard · Answer 1 · Wed Jan 22 2020 21:25:55 GMT+0800 (China Standard Time)

Are you running the software from this repository, or the Keybow Python API?

Try adding this file to your system as /etc/udev/rules.d/10-keybow.rules:
https://github.com/pimoroni/picade-hat/blob/master/etc/udev/rules.d/10-picade.rules

It should work and, if so, we clearly need some documentation/installer changes.

wildestpixel · Answer 2 · Wed Jan 22 2020 23:31:22 GMT+0800 (China Standard Time)

Thanks Phil,

Will try that this evening - is it okay i create the /etc folder in the root of the /sdcard structure of the keybow firmware ?

Just seems weird not having the normal file layout where /etc /usr et al exist in an image whether in the boot or root filesystems.

Philip Howard · Answer 3 · Wed Jan 22 2020 23:42:13 GMT+0800 (China Standard Time)

I'm confused- what software are you running to drive your Keybow? This keybow firmware shouldn't even boot on a Pi 4. Could you walk me through your setup/how you created it?

wildestpixel · Answer 4 · Wed Jan 22 2020 23:46:50 GMT+0800 (China Standard Time)

I'm running the keybow firmware 0.0.4 unzipped on a pi zero w which is attached by usb to a pi4.

It passes mpd commands as a keyboard to the pi4 which plays music

So - my keybow on a zero-w is controlling a pi4 instead of say controlling media on my Mac or PC.

Philip Howard · Answer 5 · Wed Jan 22 2020 23:52:43 GMT+0800 (China Standard Time)

Aaaah! That makes sense. In that case the file linked above wont help you. I'd assumed Keybow HAT was connected directly to the Pi 4.

In this case I'm not 100% sure what's going on, but the fix may be a similar file added to your Pi 4- the keybow being a composite device (Serial and other nonsense alongside USB) might make it not detect correctly as a HID keyboard.

I'll try to replicate and figure out a fix.

Philip Howard · Answer 6 · Thu Jan 23 2020 00:06:38 GMT+0800 (China Standard Time)

Okay- on your Pi 4 you need to create a new file: /etc/udev/rules.d/10-keybow.rules

With the content:

SUBSYSTEM=="input", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0ec4", ENV{ID_INPUT_KEYBOARD}="1"

This basically just tells linux that Keybow is a keyboard.

wildestpixel · Answer 7 · Thu Jan 23 2020 03:18:17 GMT+0800 (China Standard Time)

Seems the udev rules dont work and it could be a boot timing issue meaning the device isn't recognised at boot as a gadget.

Either the pi4 or the keybow boot too quickly and that has a bearing on whether the keybow shows up in lsusb

So compiling https://github.com/codazoda/hub-ctrl.c

and running

sudo ./hub-ctrl -h 1 -P 3 -p 1

brings the port to life and the device then shows up in lsusb :
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So throwing (for example)

sudo /home/pi/hub-ctrl -h 1 -P 3 -p 1

into /etc/rc.local whilst lacking any elegance is working for me presently.

Note the vendor id and product id of the keybow in the above lsusb - changing the udev rule to incorp these values doesn't help.

Synopsis is that on a device that has no other keyboard attached, it is boot timing that is having a bearing on recognition of the keybow (if this synopsis is correct).

Just wished for a more elegant solution than ive found.

wildestpixel · Answer 8 · Tue Feb 11 2020 16:03:14 GMT+0800 (China Standard Time)

Can now confirm power cycling issues are back and Keybow hangs - regardless of whether logitech keyboard dongle is attached or not and whether i run hubctrl. You cannot use keybow on pi4 unless its detached and reattached from USB port. When you reboot its stuck with all of the lights stationery.

pi@quattro:~ $ sudo rpi-eeprom-update
BCM2711 detected
BOOTLOADER: up-to-date
CURRENT: Fri 17 Jan 17:37:11 UTC 2020 (1579282631)
LATEST: Fri 17 Jan 17:37:11 UTC 2020 (1579282631)
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad

pi@quattro:~ $ uname -r
4.19.97-v7l+

pi@quattro:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Even when seen in lsusb as 1d6b:0104, if the lights aren't moving the device isn't working

wildestpixel · Answer 9 · Thu Feb 13 2020 17:32:49 GMT+0800 (China Standard Time)

Problem is solved by now introducing an inline USB power-switch between the pi and the keybow!

The Pibow hangs and the toggle the power switch.

In the absence of a working software solution this was a further expense to make the already significant Pibow investment workable attached to the Pi4.

Should there be an advisory on sales description on Pimoroni website to state that product is "not guaranteed to survive reboots when attached to a Pi" ?