> 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
>
No comments:
Post a Comment