[libhid-discuss] help

[Roberto Diaz]

Hello,



I'm developing an application that would communicate with an HID device
either through interrupt or control transfers. So far, I have succeeded with
HID control transfer by using "libhid" any how I have a problems using both
the hid_interrupt_write( ) and hid_interrupt_read( ) functions. I'm using as
skeleton program the lshid.c example file that is provided by
libhid-0.2.16.tar.gz package, I'm simply changing the hid_set_output_report
function ( this function is correctly working for the same device) with the
hid_interrup_write( ) funtion; and this is the output messages that I get
when I'm using hid_interrup_write( ).





NOTICE: hid_force_open(): successfully opened USB device 001/005[0].

************************************************************************

Sending Report...***.

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

TRACE: hid_close(): closing USB device 001/005[0]...

TRACE: hid_close(): closing handle of USB device 001/005[0]...

NOTICE: hid_close(): successfully closed USB device 001/005[0].

TRACE: hid_reset_parser(): resetting the HID parser for USB device
001/005[0]...

TRACE: hid_close(): freeing memory allocated for HID parser...

TRACE: hid_close(): resetting HIDInterface...

ERROR: hid_reset_HIDInterface(): ************NULL HIDInterface reseted.

NOTICE: hid_cleanup(): successfully deinitialised HID library.







This is the source code that I'm using



/* data init */

for (i = 0 ; i < 32 ; i++)

hid_id[i] = NULL;



ret = hid_init();



hid = hid_new_HIDInterface();

matcher.vendor_id = HID_ID_MATCH_ANY;

matcher.product_id = HID_ID_MATCH_ANY;

matcher.matcher_fn = device_iterator;



/* open recursively all HID devices found */

while ( (ret = hid_force_open(hid, 0, &matcher, 2)) !=
HID_RET_DEVICE_NOT_FOUND)

{


printf("********************************************************************
****\n");



//hid_write_identification(stdout, hid);



/* Only dump HID tree if asked */

/* hid_dump_tree(stdout, hid); */



char packet2[4] = { 0x07, 0x01, 0, 0, 0, 0, 0,0,0};

unsigned int timeout = 1000; // milliseconds



ret = hid_interrupt_write(hid, 0x01, packet2, 9, timeout);



hid_close(hid);

}



hid_delete_HIDInterface(&hid);

ret = hid_cleanup();



return 0;



I hope that someone can help me to understand what is happening or what I'm
doing wrong.



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.



Thanks in advance for your comments



Robert.

































-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/libhid-discuss/attachments/20100617/2c4ba950/attachment.htm>

[Peter Stuge]

Hi Roberto,

Post by Roberto Diaz
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.)

Post by Roberto Diaz
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.

Post by Roberto Diaz
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

[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,

Post by Roberto Diaz
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.)

Post by Roberto Diaz
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.

Post by Roberto Diaz
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