I am sending this mail to the bugreport with ACK from upstream.
---- Mail from: Josua Dietze ----
Didier Raboud schrieb:
On the Debian front, I had a very interesting mail exchange with a bug
reporter
you might really be interested in : http://bugs.debian.org/527122
I read parts of it. It made clear to me that a Debian package
suggests a ready-to-eat solution which usb_modeswitch is not (yet).
It might be helpful to point people more explicitly to the existing
documentation to prevent misconceptions.
In short, the idea is to find a clear and clean answer for "out-of-the-box"
working devices and a clear and clean workaround for the multiply defined
DeviceVendor:DeviceProduct pairs.
Yes, I understand that, including the unique ID.
The point is that it's really easy to build that "database" with
folders and individual config files which can be accessed with the
-c option. No extra C coding required.
Example (without the wrapper mechanism yet):
... RUN += "usb_modeswitch -c /etc/<to_db>/19d2/2000/zte626_a"
with "zte626_a" being a little config file with just the values of
this device and the first MessageContent (and probably "zte626_b"
with the second one). Of course, the folders can be determined by
variables. The "UID" cannot, but here the wrapper might come in IF
there is more than one config file in the product ID folder.
I'm pledging for a human readable UID, by the way, like a shortened
device model name.
These two-line entries are suspicious anyway. I doubt there are so
many ambiguities with a single model. The problem is that my only
source of information is a user community of very mixed knowledge
levels. Sometimes even the driver detachment might initiate a
(delayed) switching, and any MessageContent would seem to work.
That's annother reason I'm hesitating to offer automatic
determination inside the program.
c) A new binary (or script) (e.g. um-wrapper) is able to detect which devices
are plugged and, when launched, will prompt the user with "Do you want to
flip-flop device "DV:DP" <name from the database> device?" or "Which of the
following devices <list from the database> do you want to flip-flop?".
This would be a simple bash dialog.
D'accord.
But no matter if it's the program itself or a shell script, it is
highly unusual to require any user interaction initiated from an
udev rule. And to do that cleanly it would have to be integrated in
the mainstream desktop environments respectively. I'm afraid I'm too
busy (or lazy) to choose that path ...
My original idea was to have a helper app or script that is started
once when installing the package, with a hint to run it again for
installation of new devices.
This tool tries to recognize the device, sets all parameters, helps
with testing (even multiple switching commands per device) and stays
out of sight afterwards.
Anyway, the "database" structure would make rules creating a lot
easier; I already thought about splitting the config file, but was
not sure how to structure it.
Of course you can post my answer to the bug site.
I'll try to follow the discussion there from now on.
Cheers,
Josh
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
