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
