On Mon, 23 Apr 2007 20:08:03 +0100 (BST)
Iain Hibbert <plunky@rya-online.net> wrote:


> >
> > I have no idea what the different feature numbers mean, nor why the
> > reportids slowly diverge from the uhid numbers...
> 
> I think "usbhidctl -r" might be able to give some more verbose
> information about that
> 
> the report IDs are just labels so far as I understand, they have no
> intrinsic meaning, except to allow multiple handlers as above; the
> uhid numbers are allocated sequentially by uhidev(4), I presume there
> are gaps in the report id's ? (123 will be the maximum value, not the
> quantity)

Right; there are 48 uhid devices, with 123 the maximum report value.
> 
> I think that feature reports are for 'device status' information
> rather than 'data input', the number is the size (in bytes) of the
> report
> 
> I don't know why they choose to have 48 different reports instead of
> one larger one, what information does apcusbd use?

No clue.
> 
> if apcusbd prefers to attach as a ugen, it probably interprets the HID
> protocol itself (not that difficult), or just ignores parts of it. In
> order to make it use uhid, it would probably have to open the whole
> bunch of devices, making it complex.

Sure, but this is all hidden from apcupsd by something in the Linux API.
> 
> I suppose, without looking very deeply into it, that the simplest way
> to handle that is to make uhidev(4) ignore the device (as Matthias
> almost said)

I agree; the question is how best to do that.  My current suggestion
is a sample line, commented out, in GENERIC.  We could put a ugen-only
table in the kernel for devices that uhid should ignore, but that's a
lot more work if done right, hence my suggestion. 



		--Steve Bellovin, http://www.cs.columbia.edu/~smb