> dmesg | grep "uhid. at uhidev4"
Yepp, this one is good for manual device identification, but I was
hoping for a more direct way to be used in a hotplugd script, executed
on each device attachment, to avoid any race conditions and peaks of
high load (on a physical USB hub with multiple HID devices there could
be dozens of uhid instances that are all reported at the same moment
when a hub is attached). But it looks like there's no way at this moment
to get this info apart from dmesg.
Ideally hotplugd would allow to filter devs by vendor/product (as devd
in FreeBSD) or at least to report them. It looks like hotplug(4) could
be rather easily extended to also report parent (like in
hotplug_device_attach(cd->cd_class, dev->dv_xname, *parent*) at
407@sys/kern/subr_autoconf.c) and maybe even bus so hotplugd could be
extended to query all properties of the reported device.
Regards,
Anatoli
On 25/8/19 12:28, Bruno Flueckiger wrote:
On 24.08., Anatoli wrote:
Hi Bruno,
AWESOME!! Thanks a lot! You can add "MX Vertical" to the list of the
successfully tested pointing devices :D
I just made some minor changes as this mouse only has 2 additional physical
buttons (no secondary wheel, nor anything else). I removed the WAxis and
lowered the button numbers on the ZAxis:
Section "InputClass"
Identifier "Logitech MX Vertical"
MatchDriver "ws"
Driver "ws"
Option "Buttons" "16"
Option "Device" "/dev/wsmouse"
Option "Floating" "false"
Option "ZAxisMapping" "6 7"
EndSection
And adjusted xmodmap:
xmodmap -e "pointer = 1 2 3 8 9 4 5 6 7 10 11 12 13 14 15 16"
This way everything works as expected! Nice!
Thanks for reporting back your success. I like to read that my writing
is useful to others. The mapping of the axes to the different buttons
will vary for most devices. But if my article gave you what you needed
to get it running yourself my goal is reached.
Some time ago I also saw your other great guide about extra keys on USB
keyboards (https://www.bsdhowto.ch/extrakeys.html) and used some ideas from
it. I'd like to suggest one thing though: not to run usbhidaction from rc
(it could be started under regular users from their WM startup scripts) and
not to put the actual commands in the usbhidaction config, but rather to
call from there xdotool for each button with the key codes to generate (e.g.
"xdotool key XF86Mail" XF86LaunchA-Z, XF86AudioPlay/Stop, etc.) and then to
capture them with xbindkeys.
I do not use any X11 tools on purpose. It is my goal to describe a way
that works independently from X11.
If you exec programs directly by usbhidaction the way you launch it, they'd
be executed under root and some users reading your guide may not understand
the implications. Also this way it's impossible for each user to customize
the actions.
You're right about the security implications and the lack of multiuser
support in my article. From a security perspective it is better to run
usbhidaction as an unprivileged user. rc allows this by setting the user
parameter like this:
$ doas rcctl set user <loginname>
I've updated my article to include this setting. By the way it also
solves some trouble when you try to send commands to other media players
like moc (https://moc.daper.net/) which check for security.
The lack multi user support is left to the reader as an exercise :-)
I tried to go even further and to detect the keyboard when it's attached
with hotplugd & usbdevs/lsusb (for vendor/product IDs), but then I couldn't
solve the link between uhidev & uhid instances
(https://marc.info/?l=openbsd-misc&m=156499209423144&w=2). Please let me
know if you have any idea how to solve this.
Regards,
Anatoli
I would try to grep the output of dmesg(8) for the uhids attached to the
uhidev. Something like that should give you a list of uhid belonging to
the uhidev that got just attached:
dmesg | grep "uhid. at uhidev4"
Cheers,
Bruno
