Le jeudi 14 mai 2009 20:00:15, vous avez écrit : > 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.
Hi Josua, Concerning the existing documentation, the two standard places for that are fulfilled : the Homepage field (available in the package managers and from http://packages.debian.org/sid/usb-modeswitch ) and the /usr/share/doc/usb-modeswitch/README.gz from your tarball. If you have suggestions to improve this, please do ! > > 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. This could be really good. > I'm pledging for a human readable UID, by the way, like a shortened > device model name. No problem for me. Good idea by the way ! As long as the identifier stays constant along future releases, it's clearly OK with my distribution hat on. > >> 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 idea was not to have a dialog initiated by a hal .rules but to have a simple wrapper which any user can launch. This wrapper could have an option like --non-interactive which could do the actual switch if the DV:DP:UUMID is unique and do nothing (return error) if not. > 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. I think that a tree under /usr/share/usb-modeswitch/devices_database/ (why not being verbose…) would be really good. The placement under /usr is because those files are not supposed to evolve. Any addition to the tree would be no problem. The tree structure is up to you (you are upstream afterall ;) ;) ), but I think that 19d2/2000/zte626_a as you proposed is good. > Of course you can post my answer to the bug site. I did forward my mail and yours to the bugreport. This one is CCed to the bugreport. If you can keep the bugreport CCed, we keep the trace publicly so that others can know what happens. > I'll try to follow the discussion there from now on. Cool. > Cheers, > Josh What are your plans for future releases ? Doing the split of the configuration files could be a good first step. Then, the detection-and-prompting wrapper can be written in simple bash or something similar and I can handle the auto-detection .rules file (as now). Best regards, OdyX -- Didier Raboud, proud Debian user. CH-1802 Corseaux did...@raboud.com
signature.asc
Description: This is a digitally signed message part.
