Re: usb device modifying state of another driver on plug/unplug event

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Wed, Jun 19, 2019 at 08:01:43AM +0930, Brett Lymn wrote:

> Yes, that looks useful.  It would be a good if we had a way of
> identifying the device being attached so that I can disable the trackpad
> if, specifically, a mouse is attached not a keyboard or even usb flash
> drive.

The only way to identify a device is its driver name. So it is pretty
trivial to identify mice (ums), keyboards (ukbd) or flash drives (umass).

But what if you have two mice and want one to have precedence over the other?

Most USB mice report a hopefully unique serial number (usbdevs -v shows
them). You could also select by vendor/product numbers that may or may
not be unique. But non-USB devices may not have this advantage.

You could also follow the device topology (what attached where), but
that often just identifies the attachment order (what attached first)
as there are no identifiable ports. Some systems might expose what
ports exist, even their physical location. Others don't.

The dmesg output reveals more about device identity, but that largely
depends on how verbose the driver is. Most drivers also expose some
API to retrieve the same information, but for example pms (PS/2 mouse
driver) doesn't.
I have modified some disk drivers to push that information into the
device properties that you can query with drvctl -p. But that's an
exception.


So we can probably satisfy your specific requirement, i.e. prefer USB
mouse (ums*) over internal touchpad (pms0). But there isn't anything
for the general case.


Disabling a mouse can be done without detaching the driver. Mice
automatically attach as wsmouse* to wsmux0. You can use wsmuxctl
to attach/detach specific mice. A simple strategy would be to
keep the highest numbered wsmouse* device as internal devices
usually attach before external ones, but that's not a guarantee,
in particular if the internal device is also USB.

This devpubd hook has an even simpler strategy, use the last
mouse attached and fall back to internal if that mouse is
detached.

#!/bin/sh

event=$1
shift

keepmouse()
{
	for mouse in $(wsmuxctl -f /dev/wsmux0 -l); do
		wsmuxctl -f /dev/wsmux0 -r $mouse
	done
	wsmuxctl -f /dev/wsmux0 -a ${mouse:-wsmouse0}
}

for device in "$@"; do
	case $device in
	wsmouse*)
		keepmouse
		;;
	esac
done


If wsmux would expose the various mice, it would be nicer as the
X server could know about it. You could then use xinput to configure
inputs and even use different mice (or touchpads or tablets or ...)
for different purposes. Currently you can tell X to use the uhid
devices directly to get that result, but I don't think we support
hot-plugging.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."