[libhid-discuss] libhid problems with interrupt_read/write

[Thomas Maclean]

Ugh.  Sorry.  I had been using some online doxygen docs for hid.h and it
hadn't occured to me that it could change.  Lesson learned.

I am pretty sure I'm linking against the same distribution of libhid
because I only have that one version (installed in /usr/local/lib ).

Wow ... in my world (embedded telecom systems) 100 msec is a long time!
I'll try increasing the timeout a bit.  My CPU is reasonably fast (1 GHz)
- no rocket, but not some embedded 33 MHz processor.

I tried printing the usb_strerror() when I get error returns from my hid
calls, but mostly the returned string says something along the lines of
the device was busy or anavailable.

I was looking for ways to 'clear' the error on the pipe (i.e. after I get
a timeout, all subsequent reads fail.)  I thought I had something
to clear the error by performing a zero-byte read, but I don't think this
does anything.  The odd thing I noticed when doing this is that when I
try to read 8 bytes and I get a timeout, the warning tells me I got zero
bytes.  When I subsequently perfrom a zero-byte read, the warning tells me
that I requested 0 bytes, but it sent 8 (though the read buffer seems
empty).

More experimantation coming....

Regards,

Tom M.

On Fri, 6 Apr 2007, Charles Lepple wrote:

> On Apr 5, 2007, at 4:07 PM, Thomas Maclean wrote:
>
> > I'm also getting writes that return with value 23!  My count of the
> > enum
> > for the hid_return values doesn't go that high!
>
> SVN rev 330 (hid.h last changed: 313) says that we added two items to
> hid_return, so 23 is HID_RET_TIMEOUT.
>
> 100 ms is short for a 1.5 Mbit/sec USB device. Bear in mind that it's
> both the time needed to transmit the bits (which can be long for a
> multi-frame packet) plus whatever response time the device needs to
> ACK the whole packet (which might take a while if it is a slow
> processor).
>
> Are you sure that your code is linking against the same installation
> of libhid as the hid.h header file?
>
> Also, you might want to make sure all compiler warnings are turned
> on. I might have accidentally introduced a regression somewhere.
>
> > 'cat /proc/bus/usb/devices' returns
> >
> > T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=1.5 MxCh= 0
> > D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> > P:  Vendor=10bf ProdID=0004 Rev= 4.00
> > S:  Manufacturer=SmartHome
> > S:  Product=SmartHome PowerLinc USB E
> > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
> > I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=(none)
>
> "Driver=(none)" means that the kernel is not claiming the HID
> interface, which is good (as I don't know if libusb-0.1.8 has the
> detach function needed to kick the kernel out of the way).
>
> --
> Charles Lepple
> clepple at ghz.cc
>
>