[Nut-upsdev] Changes to usbhid-ups driver

[Peter Selinger]

Hi Arjen,

this certainly sounds like a good idea. However, this requires a lot
of changes and testing. Perhaps it's more of a long-term plan? Can you
think of a sequence of small, easy-to-test changes that would
gradually lead from here to there?

One potential problem is that opening devices often requires detaching
a linux kernel driver, and this can lead to mice and keyboards
disconnected. So if there is, for example, a Belkin mouse, then there
is a bit of a catch: you don't know if it's a UPS until you open it,
but by the time you have opened it, it's already too late. 

Perhaps we are fixing a problem that nobody is having. I have not seen
any report on any of the mailing lists by somebody who actually needed
to distinguish devices by serial number, but couldn't.

A more minimalist solution would be to leave the exact matcher as it
was, and wait until someone logs a feature request. 

The current mechanism for device recognition, by which the -x
productid option will cause the drivers to match devices that it would
otherwise ignore, seems to work reasonably well. It allows people to
attache new devices without getting SVN sources or upgrading. The only
problem is that log message that needs to be at debug level 0, so that
people will actually know about the feature. 

-- Peter


Arjen de Korte wrote:
> 
> Peter,
> 
> What is your opinion on the following idea. I think we can improve the
> matching a lot, by delaying the exact matcher to *after* parsing the
> Report Descriptor and applying subdriver specific routines to get to the
>   serial number, model and vendor names. By doing so, we would probably
> get more accurate information on especially the serial number, since
> this is located in non-standard locations for several subdrivers. If we
> get a match, we could be sure that this is the same device and need not
> DELCMD/DELINFO whatever we got already, but could simply update the
> pointers to the parsed report descriptor (which is a lot lighter on the
> load).
> 
> Another thing is that we could probably reject devices (also, depending
> on whether a subdriver supports this) if they are not a UPS. We could
> easily check for this in the HID tree. This in turn could mean that we
> can be far less strict on matching the ProductID, since we could reject
> devices that don't report themselves as a UPS or Powerdevice.
> 
> Any thoughts on this? Could this be worthwile to investigate further, or
> am I missing something vital here?
> 
> Best regards, Arjen
>