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 >