Hi,
On Tue, Dec 17, 2019 at 06:57:54PM +0000, Raf Czlonka wrote:
> I use a Philips USB foot pedal[0] as an additional input device.
> With usbhidaction(1), I can "program" its four "buttons".
>
> After recent changes to uhid(4) device nodes' permissions, my USB
> foot pedal "stopped working".
>
> I understand that it is a *very recent* change but I rely on this
> input device for my day-to-day computer usage and have a couple of
> questions. I understand that the below permissions are final(?).
>
> crw------- 1 root wheel 62, 0 Dec 16 11:17 /dev/uhid0
> crw------- 1 root wheel 62, 1 Dec 16 11:17 /dev/uhid1
> crw------- 1 root wheel 62, 2 Dec 16 11:17 /dev/uhid2
> crw------- 1 root wheel 62, 3 Dec 16 11:17 /dev/uhid3
> crw------- 1 root wheel 62, 4 Dec 16 11:17 /dev/uhid4
> crw------- 1 root wheel 62, 5 Dec 16 11:17 /dev/uhid5
> crw------- 1 root wheel 62, 6 Dec 16 11:17 /dev/uhid6
> crw------- 1 root wheel 62, 7 Dec 16 11:17 /dev/uhid7
>
> I use(d) the below script (executed from .xsession) in order to
> configure and use the foot pedal:
>
> #!/bin/sh
> test -r $HOME/.footpedal.conf && {
> pgrep usbhidaction > /dev/null ||
> usbhidaction -f $(dmesg | awk '/Footcontrol USB/ {
> getline
> getline
> print $1
> }' | tail -n 1) -c $HOME/.footpedal.conf -i
> }
>
> $ cat $HOME/.footpedal.conf
> Generic_Desktop:Joystick.Generic_Desktop:Pointer.Button:Button_1
> 1
> action1
> Generic_Desktop:Joystick.Generic_Desktop:Pointer.Button:Button_2
> 1
> action2
> Generic_Desktop:Joystick.Generic_Desktop:Pointer.Button:Button_3
> 1
> action3
> Generic_Desktop:Joystick.Generic_Desktop:Pointer.Button:Button_4
> 1
> action4
>
> 1. Shall I *simply* introduce chmod(1)/chown(8) step in the above script?
>
Yes, this is what I recommend. The good thing is that your script
already knows the exact uhid device of your footpedal, so doing a
chmod/chown for this will not automatically open all other HID
devices.
> 2. Is the situation still more of a "watch this space"?
>
Maybe. It is difficult to find a solution for such simple and generic
devices, but we generally recommend to write drivers instead of
relying on uhid(4) or ugen(4).
> 3. Is there any other way to get the uhid(4) device node (-f option) for
> a particular USB device, other than the above dmesg(8)|awk(1) hack?
>
All uhid(4) devices support the USB_DEVICEINFO ioctl which returns the
vendor/product as strings and Ids. This is what most HID code does at
the moment: scan all /dev/uhid* devices and query either
USB_DEVICEINFO or the HID class (which is even more complicated).
But you probably don't want to do ioctls from a script (doing this
from perl or python is just ugly), don't you? So you could eventually
parse output from usbdevs or the report/output from usbhidctl.
> 4. Or perhaps I'm doing it all wrong?
>
No, you're not doing it wrong. There is no better way to use your pedal.
Reyk
> Relevant bits:
>
> $ dmesg
> [...]
> uhidev1 at uhub0 port 10 configuration 1 interface 0 "Philips Speech
> Processing Footcontrol USB" rev 1.00/3.02 addr 3
> uhidev1: iclass 3/1
> uhid0 at uhidev1: input=3, output=0, feature=0
> [...]
>
> $ usbdevs -v
> Controller /dev/usb0:
> addr 01: 8086:0000 Intel, xHCI root hub
> super speed, self powered, config 1, rev 1.00
> driver: uhub0
> addr 02: 047d:1002 Kensington, USB/PS2 Wheel Mouse
> low speed, power 100 mA, config 1, rev 4.00
> driver: uhidev0
> addr 03: 0911:091a Philips Speech Processing, Footcontrol USB
> full speed, power 100 mA, config 1, rev 3.02
> driver: uhidev1
> addr 04: 1209:2301 Keyboardio, Model 01
> full speed, power 500 mA, config 1, rev 1.00, iSerial Ckbio01
> driver: umodem0
> driver: uhidev2
> driver: uhidev3
>
> [0]
> https://www.dictation.philips.com/gb/products/transcription-accessories/foot-control-acc2300/
>
> Thanks in advance,
>
> Raf
>
