[libhid-discuss] help

[Roberto Diaz]

Hi Peter,

Thanks for your comments Peter.

This is the usbmon outout that I get when I use the hid_interript_write()
function...

e14a3c00 1245830424 S Ci:1:006:0 s 81 06 2100 0000 0009 9 <
e14a3c00 1245830609 C Ci:1:006:0 0 9 = 09211001 0001222f 00
e14a3c00 1245831429 S Ci:1:006:0 s 81 06 2200 0000 002f 47 <
e14a3c00 1245831610 C Ci:1:006:0 0 47 = 06b0ff09 01a10109 03150026 ff007508
95098102 09041500 26ff0075 08950991
e14a3c00 1245831754 S Ci:1:006:0 s 80 06 0300 0000 00ff 255 <
e14a3c00 1245831859 C Ci:1:006:0 0 4 = 04030904
e14a3c00 1245832110 S Ci:1:006:0 s 80 06 0301 0409 00ff 255 <
e14a3c00 1245832234 C Ci:1:006:0 0 36 = 24035400 65007800 61007300 20004900
6e007300 74007200 75006d00 65006e00
e14a3c00 1245832258 S Ci:1:006:0 s 80 06 0300 0000 00ff 255 <
e14a3c00 1245832360 C Ci:1:006:0 0 4 = 04030904
e14a3c00 1245832381 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 <
e14a3c00 1245832484 C Ci:1:006:0 0 42 = 2a035400 55005300 42003900 32003600
30002000 46006900 72006d00 77006100
e14a3c00 1245832508 S Ci:1:006:0 s 80 06 0300 0000 00ff 255 <
e14a3c00 1245832610 C Ci:1:006:0 0 4 = 04030904
e14a3c00 1245832628 S Ci:1:006:0 s 80 06 0303 0409 00ff 255 <
e14a3c00 1245832734 C Ci:1:006:0 0 34 = 22033700 32003300 34003100 32003300
34003100 32003300 34003100 32003300

Thanks and regards.
Roberto

-----Original Message-----
From: libhid-discuss-bounces+robdiaz=ti.com at lists.alioth.debian.org
[mailto:libhid-discuss-bounces+robdiaz=ti.com at lists.alioth.debian.org] On
Behalf Of Peter Stuge
Sent: Thursday, June 17, 2010 6:50 PM
To: libhid-discuss at lists.alioth.debian.org
Subject: Re: [libhid-discuss] help

Hi Roberto,

Roberto Diaz wrote:
> I'm developing an application that would communicate with an HID device
> either through interrupt or control transfers.

Will this in fact be a HID class device, or was HID chosen mostly
because it is so easy to use on Windows?

On all other platforms, HID is quite the opposite; it is much more
complicated than vendor-specific, similarly to how HID is less
complicated than vendor-specific on Windows.

Unless it is in fact a human interface device, then I strong
recommend exposing a vendor-specific USB interface instead of HID.

Using WinUSB and/or libusb-1.0 it is actually possible to get a
unified API for most popular platforms. (Windows support is being
integrated into libusb-1.0.)


>   TRACE: hid_interrupt_write(): writing interrupt report to device
> 001/005[0] ...
> 
> WARNING: hid_interrupt_write(): failed to perform interrupt write to
device
> 001/005[0]: error submitting URB: Device or resource busy
> 
> hid_set_output_report failed with return code 21

Could the device firmware be the cause of this problem? It would be
most helpful to have usbmon output for this interrupt write.


> P.S. The device I'm using supports both HID interrupt and control
> transfers and I have confirm that this specific device works
> whitout problems trought a similar windows application.

On numerous occasions it has been seen that Windows requires less
strict compliance from device firmware than pretty much all other
operating systems, which has lead many developers to believe that
the firmware in their devices is OK because it works with Windows.

Unless the goal is to let the device tie into the operating system's
native HID layer then I would strongly recommend to consider instead
using a vendor-specific interface. It removes the HID layer from the
equation, and allows full freedom for using all USB features in the
firmware and driver, which can be very beneficial for applications
as well as firmware, and which also makes any debugging much easier.


//Peter

_______________________________________________
libhid-discuss mailing list
libhid-discuss at lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/