http://bugzilla.suse.com/show_bug.cgi?id=1093378
http://bugzilla.suse.com/show_bug.cgi?id=1093378#c29
--- Comment #29 from Stefan Brüns
(In reply to Stefan Brüns from comment #27)
So I doubt one could catch everything with some BLACKLIST_foo option.
IMO it would work for everything that's proved by udev. User-space tools that try to access devices directly would need explicit support, which opens a can of worms.
Thats no differentiation: 1. The device is hot-/cold-plugged 2. The kernel loads a driver and generates a udev event 3. udev starts some kind of userspace "helper", e.g. gpsd, brltty 4a. the helper *may* detach the kernel driver and use e.g. libusb, or 4b. the helper opens e.g. the tty port Breaking can happen both ways, no matter if using ttyUSB or libusb. Everything not triggered from udev typically runs in a user session, e.g. argyllcms and sigrok. These are already covered by the "uaccess" udev tag and logind.
A driver which can not accurately determine in a passive if it should be used should not be selected without manual intervention.
I fear that rule would exclude a lot of drivers.
I am very much in favor of manual intervention (which could be a single mouse click or enter key) instead of causing physical damage. *many* devices can be passively probed - many have unique USB ids, and some output sufficiently unique data, see e.g. the brltty Albatrols driver, comment #12 I think its quite stupid if a device costing several thousand euros does not support autoconfiguration, although its absolutely essential. -- You are receiving this mail because: You are on the CC list for the bug.