[Nut-upsdev] Add USB vendor/device id for Belkin F6C120-UNV

[Jonathan Dion]

On 8/29/06, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> Jonathan Dion wrote:
> >
> > Hi !
> >
> > On 8/25/06, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> > > Excellent, we did not have the ProductID for this device on file
> > > before. Jonathan will be happy :)
> > >
> > Yes indeed, really happy ^_^
> >
> >
> > > In continuation of a previous discussion about whether the newhidups
> > > subdrivers should accept all devices, or only known devices, I have
> > > changed the Belkin subdriver's claim function as follows:
> > >
> > > * accept all known UPS devices (currently 0980 and 0912)
> > > * reject all known non-UPS devices (currently 0218)
> > > * accept unknown devices if requested by the user via the '-x productid'
> > >   option
> > > * otherwise, reject unknown devices (and print a debug message suggesting
> > >   that the user try the '-x productid' option)
> > >
> > > Jonathan, do you think this behavior is an improvement? Accepting all
> > > unknown devices is not good, because it could include hubs. But
> > > rejecting all unknown devices is not good either (because it requires
> > > users to hack the source to get their unknown device to work). So
> > > allowing them to override it with the '-x productid' option seemed
> > > like a reasonable compromise.
> > >
> > > If you think this is a good idea, perhaps we should implement the same
> > > behavior for the other subdrivers as well (the tripplite subdriver
> > > already has something similar). -- Peter
> >
> >
> > I totaly agree for the idea to accept all known ID, reject all the
> > other but allow to force the use via an option.
> >
> > I was thinking of an option to specify which sub-driver to force to
> > use, totally overriding the claim function.
> > But your idea seem nice too. I suppose that when the user specify the
> > -x productid, only the vendor ID is used to detemrine which sub driver
> > to use ?
> > As I don't think there will be often new vendor ID to be supported by
> > a sub-driver, and as vendorID is enough to determine the subdriver, it
> > can do the job !
> >
> > The only hypothetical problem is if a product with the same productID
> > than the UPS but a diffrent VendorID that still is the VendorID of a
> > manufacterer making UPS claimed by a subdriver exist (low chances) and
> > the user has it on his computer (very low chances), then this device
> > will be mistaken for an UPS (if it come before the UPS in the list)
> >
> > err, let me explain with an example : The UPS has as vendorID
> > BELKIN_ID, with product ID NEW_ID, that is not known by the sub driver
> > for the moment.
> > Another equip exist that has as vendorID V_ID and as productID also
> > NEW_ID, but that is not an UPS.
> > The vendor corresponding to V_ID also make USB UPS that are supported
> > by another sub-driver (with others productID).
> > then using -x productID NEW_ID could lead to mistake the other equip
> > for the UPS. But once more, what are the chances for that ?
>
> Yes, you are right. But in this situation, the user can always give
> the '-x vendorid' and '-x productid' options together, to specify
> exactly which device he wants to connect to.
>
> The only bad situation I can think of is if we need two different
> subdrivers for the same vendor. Then this mechanism will no longer
> work unambiguously. However, that is not the case for now. If this
> happens in the future, we can easily add a '-x subdriver' option.

Totally agree. I already thought of an '-x subdriver' option. After
some thought about it, it would be better not to have to use it,
because the user shouldn't have to worry about the internal
architecture of newhidups.
For the moment, -x vendorid and -x productid are enough as a vendorid
is enough to choose the subdriver. I prefer this solution because the
user can easilly found out the pair of Id of his UPS, thus we can make
a generic document explaining how to do this if needed.

>
> I have now updated the other subdrivers to support the same behavior
> (except the tripplite subdriver, which still suggests that the users
> should try the "tripplite_usb" driver first).
>

Could you precise the point about tripplite please ? tripplite_usb is
better than tripplite-hid ? I still have lot of thing to learn about
NUT ^_^

> -- Peter
>
> > Anyway, I think it is the safest way to automatically claim only known
> > UPS, automaticaly reject all other and has an option to force an UPS
> > to be supported
> >
> > Jonathan Dion
> >
>
>

Jonathan