Comment # 26 on bug 1093378 from Martin Wilck

I have a few remarks on this (stumbled on this while browsing hack week
projects)

Firstly, I think automation can be improved, even if no unique identification
is possible:

 1. The udev rules need to make sure that no two (conflicting) drivers grab the
same device. That should be fairly easy, create a variable that indicates a
driver has grabbed the device, and don't attempt probing any more if it has
happened already.
 2. Allow users to set something like BLACKLIST_DRIVERS="brltty" for a device.
Udev rules evaluate that variable and don't probe if set. If there are many
drivers, a WHITELIST_DRIVERS or PREFERRED_DRIVERS setting might be better.
 3. If a driver's probing is dangerous (i.e. can cause certain devices not to
respond any more, or the probing to hang, comment 13), that driver should be
last in the list of drivers tried.

Most importantly, the udev(7) man page says that "[RUN] can only be used for
very short-running foreground tasks". That's not quite true for an interactive
program. I believe some other approach has to be devised. It could be creating
a marker under /run somewhere to indicate a dubious device, or sending a dbus
event to the session manager of a logged-in user. The GUI program would be
started at login, if the marker was found, or if a dbus event was received
while logged in, create user-defined udev rules, and generate another uevent
(as you already proposed). For a device with a switch (comment 23) it'd be
useful to be able to start the GUI program manually to change the setting (I'd
expect this to show up e.g. in the GNOME device manager).

Btw I guess the "Windows way" of doing this would be to display a question mark
on top of the device icon in the system tray. But we don't have a system tray
in GNOME any more ...

Third, I fear there's little value in remembering USB devices by port or by bus
number. I'd suggest remembering the setting either until the device is plugged
out, or forever, at user's discretion.

Fourth, a list of device descriptions as in comment 23 looks is hard to get
right. The usability depends on the availability of a good device data base,
which is very hard to obtain and maintain. Lots of such devices are OEM
devices, so the same device may ship with various different brand names. It
might be better so simply list the available high-level drivers / consumers
with an explanation what the driver is for, e.g. 

 - brltty (Braille display)
 - gpsd (GPS device)
 - upowerd (Power meter)
 - ttyUSB (Serial converter)

That's more technical and less "user friendly" at first sight, but IMO less
confusing.