<br><div class="gmail_quote">2011/11/3 Stanislav Brabec <span dir="ltr"><<a href="mailto:sbrabec@suse.cz">sbrabec@suse.cz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Charles Lepple wrote:<br>
> On Nov 2, 2011, at 2:06 PM, Stanislav Brabec wrote:<br>
<br>
</div><div class="im">> IMHO, we only want NUT to claim these invalid USB IDs if the user<br>
> specifically requests it, rather than including it in the base NUT<br>
> distribution (think Gstreamer's "ugly" vs "good" plugins.)<br></div></blockquote><div><br>indeed!<br>we previously included these buggy IDs, but was generating more general issues than it was solving.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> Arnaud, do you think it is worthwhile to split this off into a second<br>
> udev/hotplug configuration file? (I ask since I think either you or<br>
> someone else at Eaton wrote the script that generates the .<a href="http://rules.in" target="_blank">rules.in</a><br>
> file).<br></div></blockquote><div><br>yup, I did that automation to remove some more burden from our shoulders <br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
</div>I cannot tell, what is better, not handle two strange UPSes by default<br>
and tell users what they should do, or add "daemon" group permission to<br>
a device with invalid id.<br>
<br>
(But the first will probably generate more bug reports.)<br></blockquote></div><br clear="all">right, but you're only looking at it from the Suse point of view.<br>other distros handle these privileges differently, so sadly it's not a good solution :(<br>
<br>I've been thinking a bit about that recently. part of the solution is probably to:<br>- create another macro (BUGGY_USB_DEVICE) that consider these entries, but add it as commented to the .rules file.<br>- find some way to bring users attention, like sys logging, graphical notification, user manual notes or whatever.<br>
- asking these users to bug report to the manufacturer may also help in fixing the (future) situation.<br><br>One thing that may be the solution is to have more advanced rules for these specific devices, that includes the device strings (manufacturer / device name, ...) that would avoid false positive.<br>
But before being able to do so, we'll need lsusb samples from such devices!<br><br>what is sure is that we still support these buggy devices and we'll continue to do so.<br>but, we should only make it easier to these minority of users, and not create trouble to the majority.<br>
supporting buggy devices is one thing. Making it look like everything is perfect under the sun is another!<br><br>cheers,<br>Arnaud<br>-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>
Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>
Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>