http://bugzilla.suse.com/show_bug.cgi?id=1093378 http://bugzilla.suse.com/show_bug.cgi?id=1093378#c26 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.wilck@suse.com --- Comment #26 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. -- You are receiving this mail because: You are on the CC list for the bug.