# Hi Gildas, # First of all, let me rename and downgrade this bug. retitle 527122 Improvement proposal for multiply defined DV:DP pairs severity 527122 wishlist thanks
This bug is "no more" of /important/ severity but has turned into an open discussion, so downgrading to wishlist. This does not take this issue down on my TODO list though. Le mercredi 6 mai 2009 19:11:11, vous avez écrit : > You're welcome. I understand that the issue I raised might have deep > implications on the package, and I'm glad to find you open for discussion! That's my maintainer duty… Hopefully nothing special. > Glad it was as difficult for you to understand the problem than it was > for me :) It probably means though that my mail wasn't too clear. No problem. > Ok so I think there was definitely something that I overlooked there. > > IIUC now: > 1- the general case is where there is only one entry defining one > specific DefaultVendor:DefaultProduct pair. In that case, the entry is > reported with the correct parameters in /e/u/r.d/usb-modeswitch.rules > and is supposed to "Just Work". > > 2- if there is more than one entry for one DefaultVendor:DefaultProduct > pair, the first one found in /e/usb_modeswitch.conf is uncommented, the > other one are commented out. Exactly. To be precise: * Upstream ships /etc/usb-modeswitch.conf with various possible configurations for various DV:DP pairs. * My mkrules.py maintainer script transforms these configurations into a udev rules file _at build time_. * In case of multiply defined DV:DP pairs, the first one is assumed to be working and is defined as _the_ udev rule for this pair. The other conflicting ones are also inserted in the rules file, but commented. > >> Thus, I believe that it would be more elegant to have mkrules.py > >> generate a usb_modeswitch.rules file containing one line per > >> DefaultVendor:DefaultProduct pair, without any parameter to the > >> usb_modeswitch command. > > > > Some facts as I understand them : > > > > * Bad commands sent to some devices could potentially break them. > > * Some DefaultVendor:DefaultProduct strings point to multiple devices > > with different needs (different commands). > > Hmm then the actual solution isn't problem proof either. COMPLETELY ACK ! My idea was to provide a slightly better user experience than what upstream proposes and I think that it is the case for the unique DV:DP pairs but clearly something to improve for other ones. > If one device break because of the string send to it, then we can break > it with at least the two following scenarii (corresponding to the 2 > cases defined above): > > 1- there is only one entry for a said DefaultVendor:DefaultProduct in > /e/usb_modeswitch.conf but there exists a second device out there > (unknown to usb_modeswitch) with the same entry, and that device will > break if setup with the values correct for the only known device. This would warrant a bug ! > 2- there are multiple entries for said DefaultVendor:DefaultProduct in > /e/usb_modeswitch.conf and the first one contain a parameter that will > break one or several devices with the same DefaultVendor:DefaultProduct. This also, but with higher severity ! ;) > I think the problem here lies with the vendors, as IIUC, there should be > a different VendorId:ProductId per device type. Completely ACK again. Let me make a statement very clear here : usb_modeswitch (and ozerocdoff and such) are clearly patches on a broken-by-design situation, where manufacturers voluntarily play with the USB specs to provide a broken "improved user experience" for Windows© users (to get a fancy very-specific software to work with their dongle and only it). > Do you have a link concerning problems of devices that could break? Clearly not. Assuming that some devices could break is just a "don't forget the worst case possible" assumption that I use as "less-risky procedure". > There can be several approaches here, depending on how frequent it is. > > I guess we can disallow automatic switch when there is a doubt on the > device (good candidates are different devices types/models with the same > idVendor:idProduct pair). That's a good suggestion. > Or maybe we can explicitely blacklist some devices known to break and > force manual configuration? Well… A device known to break should reasonably be found to work with a special other command I think. So there is no need for a blacklist I think. > > * Some users could have multiple dongles which different needs (different > > commands). > > By setting an automatic launch of usb-modeswitch without options for each > > and every possible device listed by upstream as "potentially working", > > usb-modeswitch will be run with the options configured by the admin for > > each device, potentially breaking your havoc. > > > > I see some ways out : > > > > (1) Implement your solution "no specifics in > > /e/u/r.d/usb-modeswitch.rules" * Needs administrator configuration > > I think administrator configuration is hard to avoid for devices where > DefaultVendor:DefaultProduct is not specific to that device (i-e there > is more than one entry with that DefaultVendor:DefaultProduct in > /e/usb-modeswitch.conf). Clear. > > * Pros: > > + No manual edition of /e/u/r.d/usb-modeswitch.rules needed > > + Configuration is done in one place /e/usb-modeswitch.rules > > I guess you meant /e/usb-modeswitch.conf? Obviously. > > * Cons: > > - Works for only one device per machine > > - Launches usb-modeswitch with false commands for all other > > devices, with potential hardware breaking > > If I understand correctly, this is already the case in the actual > solution when there is more than one match for a specific value of > DefaultVendor:DefaultProduct. In that case, you will use the first entry > found in /e/usb-modeswitch.conf. > > For instance for my ZTE MF626, the value used by default was the one > from ZTE MF620. Exactly. This could be turned into a "no way" for multiply defined DV:DP pairs. What do you think? > > - Works correctly for machines that only get connected to one > > device of the list _ever_. > > Aha! something else I overlooked. > > I though usb_modeswitch was able to parse /e/usb-modeswitch.conf and > find the entry there that would match the connected devices. Unfortunately not ! > It seems that I was wrong: I've created a /e/usb-modeswitch.conf file > with 2 entries. It only works if my device matches the first entry. Ok, > then the title for my bug report is obviously wrong and you did the > correct thing. > > I think this is a major limitation of usb_modeswitch (it should be able > to read the entries for the _connected_ devices and run accordingly). Hum… This is a damn good idea ! It makes me wonder if a "helper script", doing this detection and prompting the possible configurations (and then launching the correct one) could be really good. Either on command-line or even graphically (but this becomes harder…). > Now I understand why you did it that way in the > /e/u/r.d/usb-modeswitch.rules, and I think README.Debian should state > explicitely that /e/usb-modeswitch.conf can only contain _one_ > uncommented entry or that it won't work as expected (unless the device > plugged is the first uncommented entry). Patches for the README.Debian are welcome but I will try to propose something. > > (3) Completely change the way upstream works with its configuration > > I suggested a more global solution in upstream's forum there: > > http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=142 > > The idea is to get rid of this database as configuration but to > > settle it down somewhere under /usr/ and then have a waaay simpler > > configuration file which then only has identifiers. > > I'm not sure I fully understand the solution. Do you mean that there > could be a way to automatically uniquely identify the plugged device and > to assign it to a specified id in the configuration DB, even if there is > more than one type of device for a single idVendor:idProduct pair? No. Clearly not. But by having a unique identifier on the software side could make a lot of things easier. > If you want to contact the upstream developper, have you tried either on > the forum sending a private message to Josh, or using the mail address > given in the source code? I did this in the past and will probably do in the future too… ;) > Well it's a tough one once you include the problems I overlooked above. > > If I take the following properties as desirable for the solution: > - work out of the box for most devices without any configuration, if > that's safe/if the user wants it that way > - allow for manual changes in one place only These are desirable goals on my side too. > I would say that ideally we would have: > > - /etc/usb-modeswitch.conf would be the only place where the changes > occurs This seems a good goal. > - one should never have to modify the udev rules file, and it should > be as independant as possible from the configuration file I agree that the user should never edit the file itself, but if there is a need that he runs a helper binary/script (# update-usb-modeswitch-udev-rules), this is in the acceptable range for me. > - if the user doesn't want the switch to happen automatically, there > is no udev rules installed A way to disable it ? Yes. Why not… > - if the idVendor:idProduct pair does not allow for identification of > a single device[1], automatic configuration for that > idVendor:idProduct pair should be disabled ACK. > - usb_modeswitch should identify the plugged usb devices and pick the > right values for them amongst the uncommented entries of > /etc/usb-modeswitch.conf OK. > - usb_modeswitch should do nothing (or optionally prompt the user) if > there is more than one entry with the same id or no id for the > plugged devices OK. > ====IDEAL CASE==== > > usb_modeswitch is changed to support the behaviour described above. > > In this case, if that's not supported by upstream already, use the > upstream usb-modeswitch.conf to create a /etc/usb-modeswitch.conf file > where entries are uncommented when the idVendor:idProduct pair is > unique. When there is more than one entry per idVendor:idProduct pair, > leave it commented (there should be a clear explanation in the > documentation about this). My proposal for the ideal case is the following : a) Upstream ships a database of unique DV:DP:UUMID (Unique Usb-Modeswitch IDentifier) triplets linked to a name and configuration value. Obvioulsy, there will be no way of distinguishing between various DV:DP:*, but they are stored in a unique way with clear names. b) As input, the usb-modeswitch binary only takes this DV:DP:UUMID triplet or a complete command-line (for testing purposes). * With a) and b), it can work the same as actual upstream, but without configuration file handling. 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?". d) For this binary, the prompting for uniquely defined DV:DP pairs can be opted out with a command-line option (--no-prompt-for-unique-dvdp-pair / --quiet). e) a /etc/udev/rules.d/usb_modeswitch.rules is shipped with only the uniquely defined DV:DP pairs with um-wrapper --quiet in all entries => out-of-the-box working for known devices. f) a /usr/share/doc/usb_modeswitch/examples/usb-modeswitch.rules is shipped with an example for autodetection for a non-uniquely defined DV:DP pair (with usb-modeswitch DV:DP:UUID in a udev rule), which the user can use on his own. g) Everything is documented in NEWS.Debian and README.Debian accordingly. This is my ideal situation ;), which even doesn't need any configuration file anymore ! I think I will go on with this (depending on your feedback obviously) and will work with upstream on this strategy… Note that this is clearly the result of your proposals and will warrant you clear thanks in the changelog file. :-D > Then, at installation time you can have debconf asking the user if it > wants automatic switch (udev support) I don't want to hassle users and translators with a debconf question. This is waay to much "hammer-to-kill-a-fly". > Hope this helps. This helps very clearly ! I am very thankful for the time you take to make usb-modeswitch better, at least in hopes… > Cheers, > Gildas Best regards, Didier -- Didier Raboud, proud Debian user and usb-modeswitch maintainer CH-1802 Corseaux did...@raboud.com
signature.asc
Description: This is a digitally signed message part.
