Re: usbhidaction(1) with a foot pedal/control
Reyk Floeter wrote: > > 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. You cannot recommend that. chmod a+rw /dev/uhid* chmod: /dev/uhid0: Operation not permitted chmod: /dev/uhid1: Operation not permitted chmod: /dev/uhid2: Operation not permitted chmod: /dev/uhid3: Operation not permitted chmod: /dev/uhid4: Operation not permitted chmod: /dev/uhid5: Operation not permitted chmod: /dev/uhid6: Operation not permitted chmod: /dev/uhid7: Operation not permitted So he'll use doas. Which just reinvents the disaster. > > 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. Sorry, that means it is wrong. There is code missing. That code has to be written.
Re: usbhidaction(1) with a foot pedal/control
Hi,
On Tue, Dec 17, 2019 at 06:57:54PM +, 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: 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
>
Re: usbhidaction(1) with a foot pedal/control
Raf Czlonka wrote:
> Hi all,
>
> 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
Final.
Things might get tightened further.
> 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?
Your .xsession doesn't run as root, so I expect some security comedy
where you use 'doas' in your .xsession, and then all your applications
can doas.
I expect it will go poorly.
> 2. Is the situation still more of a "watch this space"?
Perhaps.
There should probably be a usb joystick driver, which can be managed
with fbtab, or this should be integrated into ukbd.
None of that is easy.
> 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?
usbdevs -vv might provide better information about what device is exported
as what, but again the listed nodes are for root use only.
But the entire configuration and handling you're about to do is
really fragile.
> 4. Or perhaps I'm doing it all wrong?
Everyone was doing it wrong. The concept of exposing all arbitrary unknown
devices directly to userland, and writing userland drivers is crazy.
We don't have answers for how to fix this yet, but people on the average
host shouldn't be automatically registered into the unsafe model.
usbhidaction(1) with a foot pedal/control
Hi all,
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?
2. Is the situation still more of a "watch this space"?
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?
4. Or perhaps I'm doing it all wrong?
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: 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
