tags:

views:

1279

answers:

2

I’m interested in using libhid to access a custom HID device that we are developing on a PIC microcontroller. I have been able to successfully get the test_libhid code to run. The instructions for reading and writing to devices using this library are provided as comments in the test_libhid code.

I have attempted to follow the documented techniques for reading and writing, but so far, I have not been to successfully read or write to the device. I suspect the reason may be that the report descriptor for the device specifies a 64 byte array for both the input and output data reports.

I have read the details contained in the Device Class Definition for HID section from usb.org, and I think that I understand how descriptors work in general and how they translate to HID paths, but my attempts to read and write data to the device have failed.

I have verified that the device works in Windows, so my problem appears to lie on the Linux side. I don’t think that it should matter, but I should note that I’m currently working in a VMWare virtual machine, loaded with Ubuntu 8.04 server

Can anyone provide some guidance on how to specify he HID path for the following report descriptor (generated from lsusb –vvv):

Report Descriptor: (length is 29)
    Item(Global): Usage Page, data= [ 0x00 0xff ] 65280 
                        (null)
    Item(Local ): Usage, data= [ 0x01 ] 1
                        (null)
    Item(Main  ): Collection, data= [ 0x01 ] 1
                        Application
    Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                        (null)
    Item(Local ): Usage Maximum, data= [ 0x40 ] 64
                        (null)
    Item(Global): Logical Minimum, data= [ 0x00 ] 0
    Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
    Item(Global): Report Size, data= [ 0x08 ] 8
    Item(Global): Report Count, data= [ 0x40 ] 64
    Item(Main  ): Input, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
    Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                        (null)
    Item(Local ): Usage Maximum, data= [ 0x40 ] 64
                        (null)
    Item(Main  ): Output, data= [ 0x02 ] 2
                        Data Variable Absolute No_Wrap Linear
                        Preferred_State No_Null_Position Non_Volatile Bitfield
    Item(Main  ): End Collection, data=none

Also, when I run the test_libhid program, it dumps the parse tree as 64 identical entries that look like this:

path: 0xff000001.0x00000000; type: 0x80

These are presumably the inputs. This list is followed by another 64 entries that look like this:

path: 0xff000001.0x00000000; type: 0x90

I have posted to the libhid mailing list, but there has not been much activity there recently, so I thought that I would bring my question here. If anyone can provide guidance on how the HID path for this input and output report should be specified, it would be a tremendous help.

Thanks.

A: 

After much trial and error, I was never able to get libhid to work with the report descriptor for my target device. I did find that the HID Device Interface (hiddev) worked very well, and was actually very easy to understand. There is a good PDF Reference for hiddev that I highly recommend. Also, the include file hiddev.h in /usr/include/linux was also very helpful. In Ubuntu 8.04, the hiddev interface worked "out of the box" with no additional configuration required.

Hopefully this will be of some help to the next person that has problems interfacing their HID device to a Linux host.

Note: The link that I provided for the .PDF file above seems to have disappeared. I posted a copy of the .PDF file here. Its a free file sharing service, so you will need to endure a few advertisements in order to download it.

Steve Hawkins
A: 

hi Steve

I have a problem someway like you had can you tell me how you write your project?

by the way the "PDF Reference for hiddev" pdf link is out i cant get it can you mail it to me

thanks

I added a note to the answer above with an alternative location that you can use to get the document. Hope it helps...
Steve Hawkins