On Mon, 23 Apr 2007, Steven M. Bellovin wrote:

> On Mon, 23 Apr 2007 18:42:59 +0200
> Manuel Bouyer <bouyer@antioche.eu.org> wrote:
>
> > On Mon, Apr 23, 2007 at 05:24:56PM +0200, Joerg Sonnenberger wrote:
> > > On Mon, Apr 23, 2007 at 04:09:56PM +0100, Matthias Scheler wrote:
> > > > Well, you could always teach uhid(4) to ignore certain devices in
> > > > which ugen(4) should get them.
> > >
> > > I think it would be better to fix apcusbd to work with uhid
> > > instead. I think that it doesn't work is mostly a linuxism.
> >
> > I'm not sure it's that easy. From what I remember an APC ups matched
> > by usbhid will attach 50 or so instances of usbhid.
>
> To be precise, 48:
>
> Apr 21 22:56:40 bigboy /netbsd: uhidev0 at uhub1 port 2 configuration 1 interface 0
> Apr 21 22:56:40 bigboy /netbsd: uhidev0: APC Back-UPS ES 725 FW:802.n2.D USB FW:n2, rev 1.10/1.06, addr 2, iclass 3/0
> Apr 21 22:56:40 bigboy /netbsd: uhidev0: 123 report ids
> Apr 21 22:56:40 bigboy /netbsd: uhid0 at uhidev0 reportid 1: input=0, output=0, feature=1
> Apr 21 22:56:40 bigboy /netbsd: uhid1 at uhidev0 reportid 2: input=0, output=0, feature=1
> ...
> Apr 21 22:56:40 bigboy /netbsd: uhid44 at uhidev0 reportid 120: input=0, output=0, feature=1
> Apr 21 22:56:40 bigboy /netbsd: uhid45 at uhidev0 reportid 121: input=0, output=0, feature=1
> Apr 21 22:56:40 bigboy /netbsd: uhid46 at uhidev0 reportid 122: input=0, output=0, feature=4
> Apr 21 22:56:40 bigboy /netbsd: uhid47 at uhidev0 reportid 123: input=0, output=0, feature=2
>
> 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)

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?

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.

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)

iain