Report ID problem with HID-RAW interface usage

Report ID problem with HID-RAW interface usage

[Amit Nagal]

Hi ,

i am trying to send a vendor specific HID report from a userspace host
program to vendor usb hid device
using HIDRAW interface .

the vendor specific report consist of < "Report ID " (0th position ) >
followed by <  "payload of data "  > .
when i send report in this format , i am not getting report response
from the usb device .

but when i send report in the format  < "Report ID "(0th byte ) >
<Report ID (1st byte )> < "data payload ">
i am getting perfect report response from usb device .

when i debugged kernel source code , i found the  function
usbhid_output_raw_report function defined in
drivers/hid/usbhid/hid-core.c
responsible for report transfer , where we use usb_control_msg as  :

ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
		HID_REQ_SET_REPORT,
		USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
		cpu_to_le16(((HID_OUTPUT_REPORT + 1) << 8) | *buf),
		interface->desc.bInterfaceNumber, buf + 1, count - 1,
		USB_CTRL_SET_TIMEOUT);


As we can see above we are passing   " buf + 1 "  , " count - 1 "  to
data and size parameters of usb_control_msg()  function ,
which effectively means that if i make my report  format as <report id
>  < payload >
then in the  data parameter of usb_control_msg function , report id is
stripped off () .
and thats why i am not getting response with above report format .

report responses comes fine if  i  modify usb_control_msg usage as below :

ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
		HID_REQ_SET_REPORT,
		USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
		cpu_to_le16(((HID_OUTPUT_REPORT + 1) << 8) | *buf),
		interface->desc.bInterfaceNumber, buf , count ,
		USB_CTRL_SET_TIMEOUT);

here i passed complete buf and count thereby passing < report id >
also in data params of usb_control_msg .

kindly provide insight and clarity regarding the < report id > ambiguity .


the original usbhid_output_raw_report()  function is  copied below for
reference .

static int usbhid_output_raw_report(struct hid_device *hid, __u8 *buf,
size_t count)
{
	struct usbhid_device *usbhid = hid->driver_data;
	struct usb_device *dev = hid_to_usb_dev(hid);
	struct usb_interface *intf = usbhid->intf;
	struct usb_host_interface *interface = intf->cur_altsetting;
	int ret;

	printk("=====>[IPOD HID ][Hid-core.c]%s\n" , __FUNCTION__);

	ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
		HID_REQ_SET_REPORT,
		USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
		cpu_to_le16(((HID_OUTPUT_REPORT + 1) << 8) | *buf),
		interface->desc.bInterfaceNumber, buf + 1, count - 1,
		USB_CTRL_SET_TIMEOUT);

	/* count also the report id */
	if (ret > 0)
		ret++;

	return ret;
}


Thanx & Regards
Amit Nagal

Re: Report ID problem with HID-RAW interface usage

[Alan Ott]

On 06/29/2010 07:10 AM, Amit Nagal wrote:
> i am trying to send a vendor specific HID report from a userspace host
> program to vendor usb hid device
> using HIDRAW interface .
>
>
> but when i send report in the format<  "Report ID "(0th byte )>
> <Report ID (1st byte )>  <  "data payload">
> i am getting perfect report response from usb device .
>   where we use usb_control_msg as  :
>
> ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> 		HID_REQ_SET_REPORT,
> 		USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
> 		cpu_to_le16(((HID_OUTPUT_REPORT + 1)<<  8) | *buf),
> 		interface->desc.bInterfaceNumber, buf + 1, count - 1,
> 		USB_CTRL_SET_TIMEOUT);
>
>    

I thought I'd be able to just go check the HID specification and be able 
to say that the report number is not sent as part of the payload for 
Set_Report devices, since it would be redundant because the Report ID is 
sent over in the wValue field.

Unfortunately, I was not able to see that clearly laid out in the HID 
specification in the section on Set_Report. I did however find language 
saying "if a Report ID tag was used in the Report descriptor, all 
reports include a single byte ID prefix," in section 8.1, Report Types.

I did some tests with the Windows implementation, and indeed, when 
numbered reports are used in the HID descriptor, the Windows 
implementation will send the report ID as the first byte of the payload.

Based on the language in the HID spec, and the behavior of Windows, I 
believe the buf+1, count-1 to be a bug.

Jiri, what do you think? Can you confirm?

Alan.


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Xiaofan Chen]

On Wed, Jun 30, 2010 at 12:30 AM, Alan Ott <alan@signal11.us> wrote:

> I thought I'd be able to just go check the HID specification and be able to
> say that the report number is not sent as part of the payload for Set_Report
> devices, since it would be redundant because the Report ID is sent over in
> the wValue field.
>
> Unfortunately, I was not able to see that clearly laid out in the HID
> specification in the section on Set_Report. I did however find language
> saying "if a Report ID tag was used in the Report descriptor, all reports
> include a single byte ID prefix," in section 8.1, Report Types.
>
> I did some tests with the Windows implementation, and indeed, when numbered
> reports are used in the HID descriptor, the Windows implementation will send
> the report ID as the first byte of the payload.
>
> Based on the language in the HID spec, and the behavior of Windows, I
> believe the buf+1, count-1 to be a bug.
>

Yes I think it is a bug.

And the HID specification states:
"If a Report ID tag was used in the Report descriptor, all reports
include a single byte ID prefix. If the Report ID tag was not used, all
values are returned in a single report and a prefix ID is not included
in that report."

My understanding is like the following and testing confirms it.
1) when HID device has explicit report IDs, then the report IDs will
be transmitted on the bus.
2) when the HID device does not use report ID at all (implicit report ID 0),
then this report ID 0 is not transmitted on the bus

Reference:
http://www.microchip.com/forums/tm.aspx?m=494711
http://libusb.6.n5.nabble.com/Missing-first-byte-when-reading-HID-Feature-Reports-with-ID-td9460.html
(we spent quite some efforts to get the libusb-1.0 Windows native
HID backend to deal with report ID correctly).

-- 
Xiaofan http://sourceforge.net/projects/libusb-win32/

Re: Report ID problem with HID-RAW interface usage

[Amit Nagal]

Hi ,


Thanx for the reply .

The below discussions clears the ambiguity regarding   <report id > usage  .

I hope some patch regarding the same bug fix will be there for hidraw
interface .

Thanx & regards
Amit Nagal



On Tue, Jun 29, 2010 at 4:32 PM, Xiaofan Chen <xiaofanc@gmail.com> wrote:
> On Wed, Jun 30, 2010 at 12:30 AM, Alan Ott <alan@signal11.us> wrote:
>
>> I thought I'd be able to just go check the HID specification and be able to
>> say that the report number is not sent as part of the payload for Set_Report
>> devices, since it would be redundant because the Report ID is sent over in
>> the wValue field.
>>
>> Unfortunately, I was not able to see that clearly laid out in the HID
>> specification in the section on Set_Report. I did however find language
>> saying "if a Report ID tag was used in the Report descriptor, all reports
>> include a single byte ID prefix," in section 8.1, Report Types.
>>
>> I did some tests with the Windows implementation, and indeed, when numbered
>> reports are used in the HID descriptor, the Windows implementation will send
>> the report ID as the first byte of the payload.>>
>> Based on the language in the HID spec, and the behavior of Windows, I
>> believe the buf+1, count-1 to be a bug.
>>
>
> Yes I think it is a bug.
>
> And the HID specification states:
> "If a Report ID tag was used in the Report descriptor, all reports
> include a single byte ID prefix. If the Report ID tag was not used, all
> values are returned in a single report and a prefix ID is not included
> in that report."
>
> My understanding is like the following and testing confirms it.
> 1) when HID device has explicit report IDs, then the report IDs will
> be transmitted on the bus.
> 2) when the HID device does not use report ID at all (implicit report ID 0),
> then this report ID 0 is not transmitted on the bus
>
> Reference:
> http://www.microchip.com/forums/tm.aspx?m=494711
> http://libusb.6.n5.nabble.com/Missing-first-byte-when-reading-HID-Feature-Reports-with-ID-td9460.html
> (we spent quite some efforts to get the libusb-1.0 Windows native
> HID backend to deal with report ID correctly).
>
> --
> Xiaofan http://sourceforge.net/projects/libusb-win32/
>

Re: Report ID problem with HID-RAW interface usage

[Amit Nagal]

Hi ,

Also i want to bring to notice the following facts regarding hidraw interface :

1)

 it seems no documentation is available in the linux kernel regarding
hidraw interface usage .
it should be available like the hiddev interface file hiddev.txt .
(though  on browising over net i do find hidraw.txt , but it shud be
there in linux kernel documentation ) .

2)
no ioctl is available to fetch input / output / feature report id and size .
userspace application has to  parse report descriptor on its own and
fetch report id and size .
if some ioctl is there to fetch report id and size . it is much more
convinient for the application
to use hidraw interface .



thanx and regards
Amit Nagal

On Wed, Jun 30, 2010 at 12:39 AM, Amit Nagal <helloin.amit@gmail.com> wrote:
> Hi ,
>
>
> Thanx for the reply .
>
> The below discussions clears the ambiguity regarding   <report id > usage  .
>
> I hope some patch regarding the same bug fix will be there for hidraw
> interface .
>
> Thanx & regards
> Amit Nagal
>
>
>
> On Tue, Jun 29, 2010 at 4:32 PM, Xiaofan Chen <xiaofanc@gmail.com> wrote:
>> On Wed, Jun 30, 2010 at 12:30 AM, Alan Ott <alan@signal11.us> wrote:
>>
>>> I thought I'd be able to just go check the HID specification and be able to
>>> say that the report number is not sent as part of the payload for Set_Report
>>> devices, since it would be redundant because the Report ID is sent over in
>>> the wValue field.
>>>
>>> Unfortunately, I was not able to see that clearly laid out in the HID
>>> specification in the section on Set_Report. I did however find language
>>> saying "if a Report ID tag was used in the Report descriptor, all reports
>>> include a single byte ID prefix," in section 8.1, Report Types.
>>>
>>> I did some tests with the Windows implementation, and indeed, when numbered
>>> reports are used in the HID descriptor, the Windows implementation will send
>>> the report ID as the first byte of the payload.>>
>>> Based on the language in the HID spec, and the behavior of Windows, I
>>> believe the buf+1, count-1 to be a bug.
>>>
>>
>> Yes I think it is a bug.
>>
>> And the HID specification states:
>> "If a Report ID tag was used in the Report descriptor, all reports
>> include a single byte ID prefix. If the Report ID tag was not used, all
>> values are returned in a single report and a prefix ID is not included
>> in that report."
>>
>> My understanding is like the following and testing confirms it.
>> 1) when HID device has explicit report IDs, then the report IDs will
>> be transmitted on the bus.
>> 2) when the HID device does not use report ID at all (implicit report ID 0),
>> then this report ID 0 is not transmitted on the bus
>>
>> Reference:
>> http://www.microchip.com/forums/tm.aspx?m=494711
>> http://libusb.6.n5.nabble.com/Missing-first-byte-when-reading-HID-Feature-Reports-with-ID-td9460.html
>> (we spent quite some efforts to get the libusb-1.0 Windows native
>> HID backend to deal with report ID correctly).
>>
>> --
>> Xiaofan http://sourceforge.net/projects/libusb-win32/
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Jiri Kosina]

On Wed, 30 Jun 2010, Amit Nagal wrote:

> 1)
> 
>  it seems no documentation is available in the linux kernel regarding
> hidraw interface usage .
> it should be available like the hiddev interface file hiddev.txt .
> (though  on browising over net i do find hidraw.txt , but it shud be
> there in linux kernel documentation ) .

Alan has written nice documentation which I am going to merge soon. I am 
just waiting for Bluetooth bits to settle down, which is a little bit 
challenging with Bluetooth maintainer having been irresponsive for several 
months apparently. But it's definitely targeted for next merge window.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: Report ID problem with HID-RAW interface usage

[Jiri Kosina]

On Tue, 29 Jun 2010, Alan Ott wrote:

> > i am trying to send a vendor specific HID report from a userspace host
> > program to vendor usb hid device
> > using HIDRAW interface .
> > 
> > 
> > but when i send report in the format<  "Report ID "(0th byte )>
> > <Report ID (1st byte )>  <  "data payload">
> > i am getting perfect report response from usb device .
> >   where we use usb_control_msg as  :
> > 
> > ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> > 		HID_REQ_SET_REPORT,
> > 		USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
> > 		cpu_to_le16(((HID_OUTPUT_REPORT + 1)<<  8) | *buf),
> > 		interface->desc.bInterfaceNumber, buf + 1, count - 1,
> > 		USB_CTRL_SET_TIMEOUT);
> > 
> >    
> 
> I thought I'd be able to just go check the HID specification and be able to
> say that the report number is not sent as part of the payload for Set_Report
> devices, since it would be redundant because the Report ID is sent over in the
> wValue field.
> 
> Unfortunately, I was not able to see that clearly laid out in the HID
> specification in the section on Set_Report. I did however find language saying
> "if a Report ID tag was used in the Report descriptor, all reports include a
> single byte ID prefix," in section 8.1, Report Types.
> 
> I did some tests with the Windows implementation, and indeed, when numbered
> reports are used in the HID descriptor, the Windows implementation will send
> the report ID as the first byte of the payload.
> 
> Based on the language in the HID spec, and the behavior of Windows, I believe
> the buf+1, count-1 to be a bug.
> 
> Jiri, what do you think? Can you confirm?

Correct, it is a bug indeed.

Does any of you guys already have a patch handy which I could apply? 
Otherwise I'll fix it myself.

Thanks for spotting it,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Amit Nagal]

HI ,

is it possible to add these ioctls to hidraw interface ?

1)

ioctl with which application can get  input / output feature report and size .

2)

ioctl  which sets a flag so that when device sends a report , report
id & report type  is prefixed
to output of read() .
i mean when application calls read , it gets input report as <report
id ><report type ><payload >
right now we get <payload > only .

this kind of read() output  helps in situation where a application
specific payload is dispersed
across multiple input reports but using same report id .
the functionality which is desired above is same as provided by
HIDDEV_FLAG_REPORT
for  hiddev  interface .

Thanx & Regards
Amit Nagal



On Wed, Jun 30, 2010 at 2:26 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Tue, 29 Jun 2010, Alan Ott wrote:
>
>> > i am trying to send a vendor specific HID report from a userspace host
>> > program to vendor usb hid device
>> > using HIDRAW interface .
>> >
>> >
>> > but when i send report in the format<  "Report ID "(0th byte )>
>> > <Report ID (1st byte )>  <  "data payload">
>> > i am getting perfect report response from usb device .
>> >   where we use usb_control_msg as  :
>> >
>> > ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
>> >             HID_REQ_SET_REPORT,
>> >             USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
>> >             cpu_to_le16(((HID_OUTPUT_REPORT + 1)<<  8) | *buf),
>> >             interface->desc.bInterfaceNumber, buf + 1, count - 1,
>> >             USB_CTRL_SET_TIMEOUT);
>> >
>> >
>>
>> I thought I'd be able to just go check the HID specification and be able to
>> say that the report number is not sent as part of the payload for Set_Report
>> devices, since it would be redundant because the Report ID is sent over in the
>> wValue field.
>>
>> Unfortunately, I was not able to see that clearly laid out in the HID
>> specification in the section on Set_Report. I did however find language saying
>> "if a Report ID tag was used in the Report descriptor, all reports include a
>> single byte ID prefix," in section 8.1, Report Types.
>>
>> I did some tests with the Windows implementation, and indeed, when numbered
>> reports are used in the HID descriptor, the Windows implementation will send
>> the report ID as the first byte of the payload.
>>
>> Based on the language in the HID spec, and the behavior of Windows, I believe
>> the buf+1, count-1 to be a bug.
>>
>> Jiri, what do you think? Can you confirm?
>
> Correct, it is a bug indeed.
>
> Does any of you guys already have a patch handy which I could apply?
> Otherwise I'll fix it myself.
>
> Thanks for spotting it,
>
> --
> Jiri Kosina
> SUSE Labs, Novell Inc.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Jiri Kosina]

On Wed, 30 Jun 2010, Amit Nagal wrote:

> 1)
> 
> ioctl with which application can get  input / output feature report and size .

I am not sure I understand what exactly you mean.

hidraw intentionally doesn't interpret the reports, it's completely up to 
userspace application to do that.

> 2)
> 
> ioctl  which sets a flag so that when device sends a report , report
> id & report type  is prefixed
> to output of read() .
> i mean when application calls read , it gets input report as <report
> id ><report type ><payload >
> right now we get <payload > only .

Please see the commit 5a38f2c7c4dd53d5be097930902c108e362584a3. That makes 
sure that report id should be there properly. Do you still see any problem 
with this commit applied? (2.6.34 is the first kernel to have this one).

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Amit Nagal]

>> 1)
>>
>> ioctl with which application can get  input / output feature report and size .
>
> I am not sure I understand what exactly you mean.
>
> hidraw intentionally doesn't interpret the reports, it's completely up to
> userspace application to do that.


sorry my mistake :

what i wanted to ask was ioctl with which application can get
input / output / feature <REPORT ID > and < REPORT LEN> .

Thanx & Regards
Amit Nagal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Alan Ott]

>> 2)
>>
>> ioctl  which sets a flag so that when device sends a report , report
>> id&  report type  is prefixed
>> to output of read() .
>> i mean when application calls read , it gets input report as<report
>> id><report type><payload>
>> right now we get<payload>  only .
>>      
> Please see the commit 5a38f2c7c4dd53d5be097930902c108e362584a3. That makes
> sure that report id should be there properly. Do you still see any problem
> with this commit applied? (2.6.34 is the first kernel to have this one).
>    

That commit removes an extra byte from the beginning of reports handed 
to read(). If I understand correctly, it doesn't do what he's asking.

For devices which use numbered reports, reports which come from read() 
have the report ID at the beginning, in the form:
<report_id><payload>

For devices which do _not_ use numbered reports, only the payload is 
sent. Of course, since the device only uses a single report, a report 
number does not even make sense, and is not needed, since you know which 
report it is (as there is only one). The form is:
<payload>

It is not necessary to return the report type, because the read() 
interface will only give you INPUT reports which come over the INTERRUPT 
IN endpoint (usually EP 1 IN). FEATURE reports must come through the 
GET_FEATURE request over the CONTROL endpoint, initiated by the 
HIDIOCGFEATURE ioctl (Note that this ioctl is part of what Jiri has 
staged for the next merge window, and is not part of the current 2.6.34 
Kernel). OUTPUT reports are never sent from the device on the INTERRUPT 
IN endpoint. In short, if it comes from read(), it's always an INPUT report.

Alan.


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Jiri Kosina]

On Wed, 30 Jun 2010, Alan Ott wrote:

> > > ioctl  which sets a flag so that when device sends a report , report
> > > id&  report type  is prefixed
> > > to output of read() .
> > > i mean when application calls read , it gets input report as<report
> > > id><report type><payload>
> > > right now we get<payload>  only .
> > >      
> > Please see the commit 5a38f2c7c4dd53d5be097930902c108e362584a3. That makes
> > sure that report id should be there properly. Do you still see any problem
> > with this commit applied? (2.6.34 is the first kernel to have this one).
> >    
> 
> That commit removes an extra byte from the beginning of reports handed to
> read(). If I understand correctly, it doesn't do what he's asking.
> 
> For devices which use numbered reports, reports which come from read() have
> the report ID at the beginning, in the form:
> <report_id><payload>
> 
> For devices which do _not_ use numbered reports, only the payload is sent. Of
> course, since the device only uses a single report, a report number does not
> even make sense, and is not needed, since you know which report it is (as
> there is only one). The form is:
> <payload>
> 
> It is not necessary to return the report type, because the read() interface
> will only give you INPUT reports which come over the INTERRUPT IN endpoint
> (usually EP 1 IN). FEATURE reports must come through the GET_FEATURE request
> over the CONTROL endpoint, initiated by the HIDIOCGFEATURE ioctl (Note that
> this ioctl is part of what Jiri has staged for the next merge window, and is
> not part of the current 2.6.34 Kernel). OUTPUT reports are never sent from the
> device on the INTERRUPT IN endpoint. In short, if it comes from read(), it's
> always an INPUT report.

Ah, OK, I likely misunderstood what Amit has been actually asking for. The 
situation is exactly the way Alan has described it.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Alan Ott]

On 06/30/2010 07:14 AM, Amit Nagal wrote:
>
> sorry my mistake :
>
> what i wanted to ask was ioctl with which application can get
> input / output / feature<REPORT ID>  and<  REPORT LEN>  .
>
> Thanx&  Regards
> Amit Nagal
Amit,

There is a new ioctl() staged for the new merge window which will get 
and set feature reports. It is used like this:

         /* Set Feature */
         buf[0] = 0x9; /* Report Number */
         buf[1] = 0xff; /* data */
         buf[2] = 0xff;
         buf[3] = 0xff;
         res = ioctl(fd, HIDIOCSFEATURE(4), buf);

Is that what you're asking for, or are you asking for something which 
will tell you which reports are _available_ on the device, and what 
their lengths are? There is currently no way to report which reports are 
_available_. As Jiri said, HIDRAW does not do any parsing of the report 
descriptor. All data is passed "raw" from the user application to the 
device.

If you know what type of device you are talking to, then you shouldn't 
really need to parse the descriptor in software, because you'll know 
what the device supports, right?

Alan.

Re: Report ID problem with HID-RAW interface usage

[Xiaofan Chen]

On Wed, Jun 30, 2010 at 8:54 PM, Alan Ott <alan@signal11.us> wrote:
> Is that what you're asking for, or are you asking for something which will
> tell you which reports are _available_ on the device, and what their lengths
> are? There is currently no way to report which reports are _available_. As
> Jiri said, HIDRAW does not do any parsing of the report descriptor. All data
> is passed "raw" from the user application to the device.
>
> If you know what type of device you are talking to, then you shouldn't
> really need to parse the descriptor in software, because you'll know what
> the device supports, right?
>

Sorry I do not know much about hidraw. However, if HIDraw is so
"raw", what are the benefits of HIDRAW compared to using libusb?
Then there is also libhid which is on top of libusb.

-- 
Xiaofan

Re: Report ID problem with HID-RAW interface usage

[Jiri Kosina]

On Wed, 30 Jun 2010, Xiaofan Chen wrote:

> > Is that what you're asking for, or are you asking for something which will
> > tell you which reports are _available_ on the device, and what their lengths
> > are? There is currently no way to report which reports are _available_. As
> > Jiri said, HIDRAW does not do any parsing of the report descriptor. All data
> > is passed "raw" from the user application to the device.
> >
> > If you know what type of device you are talking to, then you shouldn't
> > really need to parse the descriptor in software, because you'll know what
> > the device supports, right?
> 
> Sorry I do not know much about hidraw. However, if HIDraw is so
> "raw", what are the benefits of HIDRAW compared to using libusb?

It's independent on transport below HID protocol. I.e. it works for 
Bluetooth HID devices as well (and any potential HID devices over 
different transport protocol that might come in the future).

> Then there is also libhid which is on top of libusb.

Which is basically comparable to hiddev -- i.e. USB only, and performs 
report processing and parsing.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: Report ID problem with HID-RAW interface usage

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Wed, 30 Jun 2010 21:04:59 +0800
Xiaofan Chen <xiaofanc@gmail.com> wrote:

> On Wed, Jun 30, 2010 at 8:54 PM, Alan Ott <alan@signal11.us> wrote:
> > Is that what you're asking for, or are you asking for something which will
> > tell you which reports are _available_ on the device, and what their lengths
> > are? There is currently no way to report which reports are _available_. As
> > Jiri said, HIDRAW does not do any parsing of the report descriptor. All data
> > is passed "raw" from the user application to the device.
> >
> > If you know what type of device you are talking to, then you shouldn't
> > really need to parse the descriptor in software, because you'll know what
> > the device supports, right?
> >
> 
> Sorry I do not know much about hidraw. However, if HIDraw is so
> "raw", what are the benefits of HIDRAW compared to using libusb?
> Then there is also libhid which is on top of libusb.
>

One of the advantages in the usb case is that you do not have to
_detach_ the kernel driver bound to the device in order to set/get
raw hid reports. With libusb this is needed.

> -- 
> Xiaofan
> 

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 0/1] HID: Send Report ID when numbered reports are sent over the control endpoint.

[Alan Ott]

This patch relies on:
  [PATCH 1/1] hidraw: Use Interrupt Endpoint for OUT Transfers if Available

Alan Ott (1):
  HID: Send Report ID when numbered reports are sent over the control
    endpoint.

 drivers/hid/usbhid/hid-core.c |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

[PATCH 1/1] HID: Send Report ID when numbered reports are sent over the control endpoint.

[Alan Ott]

The Report ID wasn't sent as part of the payload for reports which were sent
over the control endpoint. This is required by section 8.1 of the HID spec.

Signed-off-by: Alan Ott <alan@signal11.us>
---
 drivers/hid/usbhid/hid-core.c |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index deef816..1697687 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -854,14 +854,21 @@ static int usbhid_output_raw_report(struct hid_device *hid, __u8 *buf, size_t co
 				ret++;
 		}
 	} else {
+		int skipped_report_id = 0;
+		if (buf[0] == 0x0) {
+			/* Don't send the Report ID */
+			buf++;
+			count--;
+			skipped_report_id = 1;
+		}
 		ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
 			HID_REQ_SET_REPORT,
 			USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
 			((report_type + 1) << 8) | *buf,
-			interface->desc.bInterfaceNumber, buf + 1, count - 1,
+			interface->desc.bInterfaceNumber, buf, count,
 			USB_CTRL_SET_TIMEOUT);
-		/* count also the report id */
-		if (ret > 0)
+		/* count also the report id, if this was a numbered report. */
+		if (ret > 0 && skipped_report_id)
 			ret++;
 	}
 
-- 
1.7.0.4

Re: Report ID problem with HID-RAW interface usage

[Xiaofan Chen]

On Wed, Jun 30, 2010 at 9:13 PM, Antonio Ospite
<ospite@studenti.unina.it> wrote:
>
> One of the advantages in the usb case is that you do not have to
> _detach_ the kernel driver bound to the device in order to set/get
> raw hid reports. With libusb this is needed.
>

To me this is not that much an advantage. Actually libusb-1.0
has the API to re-attach the kernel driver under Linux. And we make
use of this in the new libusb-1.0 example program xusb.
http://libusb.sourceforge.net/api-1.0/group__dev.html#ga9de769d3aeb45a07f5559c8a0597cbcc
http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=examples/xusb.c;h=e260153aa50234f1c994db521969b7f0e84aebb6;hb=HEAD


-- 
Xiaofan

Re: Report ID problem with HID-RAW interface usage

[Xiaofan Chen]

On Wed, Jun 30, 2010 at 9:06 PM, Jiri Kosina <jkosina@suse.cz> wrote:

>> Sorry I do not know much about hidraw. However, if HIDraw is so
>> "raw", what are the benefits of HIDRAW compared to using libusb?
>
> It's independent on transport below HID protocol. I.e. it works for
> Bluetooth HID devices as well (and any potential HID devices over
> different transport protocol that might come in the future).

Thanks. This makes sense.

>> Then there is also libhid which is on top of libusb.
>
> Which is basically comparable to hiddev -- i.e. USB only, and performs
> report processing and parsing.
>

Some of us in the libusb mailing list have this desire to
create a real cross-platform HID API (which libhid is
trying to do but without real success -- at least under
Windows since there is no real Windows port) on top
of libusb-1.0.

The new libusb-1.0 Windows backend can directly
use the native HID API. And I create a ticket to ask
for a native HID backend for Mac OS X and I believe
it can be done.
http://www.libusb.org/ticket/33

I am not so sure if it is necessary to create a native hidraw
backend for Linux or not. But the advantage of transport-independent
HID device seems to be a good one. I think Windows native HID API
also support non-USB device. Not so sure about Mac OS X though
since I do not use Mac and do not know Mac.

-- 
Xiaofan

Re: Report ID problem with HID-RAW interface usage

[Alan Ott]

On 06/30/2010 10:02 AM, Xiaofan Chen wrote:
> On Wed, Jun 30, 2010 at 9:13 PM, Antonio Ospite
> <ospite@studenti.unina.it>  wrote:
>    
>> One of the advantages in the usb case is that you do not have to
>> _detach_ the kernel driver bound to the device in order to set/get
>> raw hid reports. With libusb this is needed.
>>
>>      
> To me this is not that much an advantage. Actually libusb-1.0
> has the API to re-attach the kernel driver under Linux. And we make
> use of this in the new libusb-1.0 example program xusb.
> http://libusb.sourceforge.net/api-1.0/group__dev.html#ga9de769d3aeb45a07f5559c8a0597cbcc
> http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=examples/xusb.c;h=e260153aa50234f1c994db521969b7f0e84aebb6;hb=HEAD
>    

Another advantage of hidraw is that the API does not depend on the 
transport. As Jiri said, it supports multiple hardware types, but beyond 
that, one does not have to worry about whether to send data over the 
control endpoint vs. interrupt endpoints, whether the report number gets 
added properly (in theory, when there aren't bugs :) ), etc.

The theory is that one can throw data at hidraw using simple read() and 
write() commands, and it comes out on the device side, without the 
client program having to know too much about USB or Bluetooth.

That's an advantage to me anyway. It's true that libusb is more flexible 
for USB devices as it handles custom class, and non-HID class devices, 
and can send data on any endpoint directly. The HID is supposed to be a 
simplified interface (limited endpoints, well-structured data, etc), so 
it makes sense to have a simplified API to communicate with it.

Think of hidraw as analogous to the Windows hid.dll API. The concepts 
are similar.

Alan.

Re: Report ID problem with HID-RAW interface usage

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

On Wed, 30 Jun 2010 22:02:00 +0800
Xiaofan Chen <xiaofanc@gmail.com> wrote:

> On Wed, Jun 30, 2010 at 9:13 PM, Antonio Ospite
> <ospite@studenti.unina.it> wrote:
> >
> > One of the advantages in the usb case is that you do not have to
> > _detach_ the kernel driver bound to the device in order to set/get
> > raw hid reports. With libusb this is needed.
> >
> 
> To me this is not that much an advantage. Actually libusb-1.0
> has the API to re-attach the kernel driver under Linux. And we make
> use of this in the new libusb-1.0 example program xusb.
> http://libusb.sourceforge.net/api-1.0/group__dev.html#ga9de769d3aeb45a07f5559c8a0597cbcc
> http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=examples/xusb.c;h=e260153aa50234f1c994db521969b7f0e84aebb6;hb=HEAD
>

AFAICS you are actually _detaching_ and _reattaching_ the driver later
in this case, with hidraw you can interleave raw reports with normal
operation from the current driver.

Think to an input device to which you'd like to set/get a certain
feature report for some reason, but that is already registered by
evdev; if you use this libusb mechanism the evdev system will see
the device disconnected and reconnected, with hidraw you just send the
report "transparently" wrt. other subsystems.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Report ID problem with HID-RAW interface usage

[Alan Ott]

On 06/30/2010 10:09 AM, Xiaofan Chen wrote:
> Some of us in the libusb mailing list have this desire to
> create a real cross-platform HID API (which libhid is
> trying to do but without real success -- at least under
> Windows since there is no real Windows port) on top
> of libusb-1.0.
>
> The new libusb-1.0 Windows backend can directly
> use the native HID API. And I create a ticket to ask
> for a native HID backend for Mac OS X and I believe
> it can be done.
> http://www.libusb.org/ticket/33
>
> I am not so sure if it is necessary to create a native hidraw
> backend for Linux or not. But the advantage of transport-independent
> HID device seems to be a good one. I think Windows native HID API
> also support non-USB device. Not so sure about Mac OS X though
> since I do not use Mac and do not know Mac.
>
>    

I've had the same ideas of creating a cross-platform HID api, and 
started a similar project. Maybe we could benefit from one another. What 
I've got so far is at:
     www.signal11.us/oss/hidapi

Of course, what's up there right now only supports Windows, and was 
originally intended to get around the fact that the HID headers and 
import lib aren't part of the Platform SDK, but part of the Driver Kit 
(It's all explained on the web page). I have a working backend for 
hidraw, which I need to get cleaned up and committed. Of course, the 
Hidraw backend depends on some of the queued changes which won't get in 
the mainline kernel until 2.6.36.

I have a Mac here and intend to make it work on OS X as well.

I did not realize that libusb-1.0 would talk to the native Windows HID 
backend. I don't see anything like that in the git version of libusb-1.0 
or libusb-win32. Is this on another branch or something, or did I miss it?

Alan.


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Amit Nagal]

Hi  ,

ok i explain my requirements again .


(1)

the hid device  i am  dealing with does not tell in its payload
protocol specifications
how many input and output reports it will support and what will be the
their respective size . the only thing it tells is payload data will
be in the format
<Report ID> <Payload > .

 >If you know what type of device you are talking to, then you shouldn't
> really need to parse the descriptor in software, because you'll know what
> the device supports, right?
>

No , this information is not available to me in advance .
the application should parse the report descriptor currently
and identify the no of input and output reports currently available
along with their sizes .

infact in my view , it does make sense to get <Report ID> <Report Len >
from report descriptor only , as a device protocol specification may change
for its  future releases . and no of reports may increase .
so its better to get this information from report descriptor only sent
by the device .


(2)

now lets consider the case for sending report to device .

different output reports have different sizes .

so depending upon application payload length ,

i have to select which < output report ID > should be used .

so hid_write should be

buff[0] =  < Output Report ID having Report Len >= application payload >
buff[1....n] = <payload data > .

since i need to know dynamically which output report id should be used
i stressed the need for ioctl which can fetch  the basic information
 <Report ID ><Report Len> parsed from report descriptor send by the device .

i agree hidraw interface sends / receives raw events and
this functionalty indeed is required by my application ,
but still to send report , i need to choose report id depending
upon application payload size .
Also report id and report length information supported is not
described in device protocol specs .

i think hidraw interface should provide support for
<report id > <report len > information as application needs to
dynamically provides information
to buff[0] = <Report ID> ( we cannot hardcode this value )

(3)

now lets consider the case for hid device read .

the syntax is read( fd , buff , count );

what i want is

buff[0]  = <Input Report ID>
buff[1...n] = <Report Payload >

Yes i agree the < Report type > information is not required .

as i explained previously one application payload can be split across
multiple reports using same <Report Id >

so if Report ID information also comes in buff[0]
it becomes easy to identify one application payload spilt across multiple
reports using same <Report ID>.


(4)

Regarding libusb / libhid usage ,
the usb device i am using is a composite device
having hid and audio interfaces .

is it possible to claim audio interface from kernel space
and hid interface from user space ?

Thanx & Regards
Amit Nagal
















On Wed, Jun 30, 2010 at 5:54 AM, Alan Ott <alan@signal11.us> wrote:
> On 06/30/2010 07:14 AM, Amit Nagal wrote:
>>
>> sorry my mistake :
>>
>> what i wanted to ask was ioctl with which application can get
>> input / output / feature<REPORT ID>  and<  REPORT LEN>  .
>>
>> Thanx&  Regards
>> Amit Nagal
>
> Amit,
>
> There is a new ioctl() staged for the new merge window which will get and
> set feature reports. It is used like this:
>
>        /* Set Feature */
>        buf[0] = 0x9; /* Report Number */
>        buf[1] = 0xff; /* data */
>        buf[2] = 0xff;
>        buf[3] = 0xff;
>        res = ioctl(fd, HIDIOCSFEATURE(4), buf);
>
> Is that what you're asking for, or are you asking for something which will
> tell you which reports are _available_ on the device, and what their lengths
> are? There is currently no way to report which reports are _available_. As
> Jiri said, HIDRAW does not do any parsing of the report descriptor. All data
> is passed "raw" from the user application to the device.
>
> If you know what type of device you are talking to, then you shouldn't
> really need to parse the descriptor in software, because you'll know what
> the device supports, right?
>
> Alan.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Xiaofan Chen]

On Wed, Jun 30, 2010 at 10:32 PM, Alan Ott <alan@signal11.us> wrote:

> I've had the same ideas of creating a cross-platform HID api, and started a
> similar project. Maybe we could benefit from one another. What I've got so
> far is at:
>    www.signal11.us/oss/hidapi
>
> Of course, what's up there right now only supports Windows, and was
> originally intended to get around the fact that the HID headers and import
> lib aren't part of the Platform SDK, but part of the Driver Kit (It's all
> explained on the web page). I have a working backend for hidraw, which I
> need to get cleaned up and committed. Of course, the Hidraw backend depends
> on some of the queued changes which won't get in the mainline kernel until
> 2.6.36.
>
> I have a Mac here and intend to make it work on OS X as well.

Great. I will forward this to the libusb mailing list.

> I did not realize that libusb-1.0 would talk to the native Windows HID
> backend. I don't see anything like that in the git version of libusb-1.0 or
> libusb-win32. Is this on another branch or something, or did I miss it?
>

It is currently being integrated into the main libusb-1.0 git tree but
the integration will take some time.

The author is Pete Batard and the tree is here.
http://git.libusb.org/?p=libusb-pbatard.git
http://www.libusb.org/wiki/windows_backend


-- 
Xiaofan http://sourceforge.net/projects/libusb-win32/
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Xiaofan Chen]

On Thu, Jul 1, 2010 at 12:40 AM, Amit Nagal <helloin.amit-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> (4)
>
> Regarding libusb / libhid usage ,
> the usb device i am using is a composite device
> having hid and audio interfaces .
>
> is it possible to claim audio interface from kernel space
> and hid interface from user space ?
>

Sure. You just need to detach the hid interface
from the kernel driver.
All in all, I think you will be better off using libusb
or libusb for what you want to achieve.



-- 
Xiaofan http://sourceforge.net/projects/libusb-win32/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Alan Ott]

On Jun 30, 2010, at 12:40 PM, Amit Nagal wrote:

> Hi  ,
>
> ok i explain my requirements again .
>
>
> (1)
>
> the hid device  i am  dealing with does not tell in its payload
> protocol specifications
> how many input and output reports it will support and what will be the
> their respective size . the only thing it tells is payload data will
> be in the format
> <Report ID> <Payload > .
>
>> If you know what type of device you are talking to, then you  
>> shouldn't
>> really need to parse the descriptor in software, because you'll  
>> know what
>> the device supports, right?
>>
>
> No , this information is not available to me in advance .
> the application should parse the report descriptor currently
> and identify the no of input and output reports currently available
> along with their sizes .
>
> infact in my view , it does make sense to get <Report ID> <Report  
> Len >
> from report descriptor only , as a device protocol specification may  
> change
> for its  future releases . and no of reports may increase .
> so its better to get this information from report descriptor only sent
> by the device .

So let me see if I understand correctly (let me know yes or no on each):
1. You do not have documentation which tells what reports are  
available on the device.
2. The number and size of reports is listed in the HID descriptor,  
which you do not want to parse in userspace. You want the kernel to do  
it for you (which is a reasonable request, as modules like hiddev  
already do this kind of parsing).
3. You want to be able to support the future releases where the report  
sizes may change.


> (2)
>
> now lets consider the case for sending report to device .
>
> different output reports have different sizes .
>
> so depending upon application payload length ,
>
> i have to select which < output report ID > should be used .
>
> so hid_write should be
>
> buff[0] =  < Output Report ID having Report Len >= application  
> payload >
> buff[1....n] = <payload data > .
>
> since i need to know dynamically which output report id should be used
> i stressed the need for ioctl which can fetch  the basic information
> <Report ID ><Report Len> parsed from report descriptor send by the  
> device .
>
> i agree hidraw interface sends / receives raw events and
> this functionalty indeed is required by my application ,
> but still to send report , i need to choose report id depending
> upon application payload size .
> Also report id and report length information supported is not
> described in device protocol specs .
>

I think I'm finally getting the picture. Again, tell me yes or no on  
each:
0. You're using HID device with User-Defined data.
1. Your device has lots of reports, which all take the same type of  
data.
2. Each report differs _only_ in its length, but the data is the same.  
For example:
	1. If you want to send 5 bytes to the device, you use report 1, which  
is 5 bytes long
	2. If you want to send 10 bytes to the device, you use report 2,  
which is 10 bytes long.
	3. if you want to send 20 bytes to the device, you use report 3,  
which is 20 bytes long.
	etc.
4. You want to know dynamically, which report you need to use, based  
on the payload length, because
4a. the only difference in your reports is the payload length.

Might I ask what kind of device this is that behaves this way?


> i think hidraw interface should provide support for
> <report id > <report len > information as application needs to
> dynamically provides information
> to buff[0] = <Report ID> ( we cannot hardcode this value )
>
> (3)
>
> now lets consider the case for hid device read .
>
> the syntax is read( fd , buff , count );
>
> what i want is
>
> buff[0]  = <Input Report ID>
> buff[1...n] = <Report Payload >
>
> Yes i agree the < Report type > information is not required .
>

For a device which uses numbered reports, the input report ID is  
always returned to read(). It's already doing what you're asking for.

> as i explained previously one application payload can be split across
> multiple reports using same <Report Id >
>

read() is going to return one report per call to read(). It's not a  
stream interface. If your data is split across multiple reports,  
you'll need to stitch it back together on your end.


> so if Report ID information also comes in buff[0]
> it becomes easy to identify one application payload spilt across  
> multiple
> reports using same <Report ID>.
>

Again, it already does this, for devices which use numbered reports.


>
> (4)
>
> Regarding libusb / libhid usage ,
> the usb device i am using is a composite device
> having hid and audio interfaces .
>
> is it possible to claim audio interface from kernel space
> and hid interface from user space ?
>

Xiaofan?

Alan.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Amit Nagal]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

> So let me see if I understand correctly (let me know yes or no on each):

> 1. You do not have documentation which tells what reports are available on
> the device.


Yes . documentation tells only that data payload will come in form
<Report ID> <Payload>
No documentation is there to tell what reports are available on device .


> 2. The number and size of reports is listed in the HID descriptor, which you
> do not want to parse in userspace. You want the kernel to do it for you
> (which is a reasonable request, as modules like hiddev already do this kind
> of parsing).

Yes . its better if kernel do it it . otherwise each application
utilising hidraw
interface will have to maintain its own parser to get this minimum information
regarding No of reports and their len .

if kernel provides this minimum info , hidraw offers a very convinient
interface to communicate with a hid device using standard
open/read/write/ioctl system calls.
and its very useful for applications which are interested in getting
raw events only from device
without dwelling much deeper into the complexities of hid specs .


> 3. You want to be able to support the future releases where the report sizes
> may change.
>

Yes. definately it is required .


> I think I'm finally getting the picture. Again, tell me yes or no on each:

> 0. You're using HID device with User-Defined data.

Yes . the device data is mostly in the form of <command > < response > .


> 1. Your device has lots of reports, which all take the same type of data.

Yes . the device has lots of inputs and output reports .
the report values are <command > < response> only .


> 2. Each report differs _only_ in its length, but the data is the same. For
> example:
>        1. If you want to send 5 bytes to the device, you use report 1, which
> is 5 bytes long
>        2. If you want to send 10 bytes to the device, you use report 2,
> which is 10 bytes long.
>        3. if you want to send 20 bytes to the device, you use report 3,
> which is 20 bytes long.
>        etc.

Yes. exactly . data  payload len is the defining parameter to
determine the report N to use .



> 4. You want to know dynamically, which report you need to use, based on the
> payload length, because
> 4a. the only difference in your reports is the payload length.
>

Yes .  Report selection should  be dynamic .

> Might I ask what kind of device this is that behaves this way?
>

it is Ipod .  i am enclosing report_descriptor and lsusb files for the same .


> For a device which uses numbered reports, the input report ID is always
> returned to read(). It's already doing what you're asking for.
>

it is ok .  read() calls returns  < report id > .


> read() is going to return one report per call to read(). It's not a stream
> interface. If your data is split across multiple reports, you'll need to
> stitch it back together on your end.
>
>

yes . i agree .


Thanx & Regards
Amit Nagal

[-- Attachment #2: lsusb_ipod.txt --]
[-- Type: text/plain, Size: 7694 bytes --]

Bus 002 Device 002: ID 05ac:1261 Apple, Inc. iPod Classic
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x05ac Apple, Inc.
  idProduct          0x1261 iPod Classic
  bcdDevice            0.01
  iManufacturer           1 Apple Inc.
  iProduct                2 iPod
  iSerial                 3 000A270013A06238
  bNumConfigurations      2
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          149
    bNumInterfaces          3
    bConfigurationValue     2
    iConfiguration          4 iPod USB Interface
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength           30
        bInCollection           1
        baInterfaceNr( 0)       1
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             1
        wTerminalType      0x0201 Microphone
        bAssocTerminal          2
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             2
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          1
        bSourceID               1
        iTerminal               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           2
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                35
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            9 Discrete
        tSamFreq[ 0]         8000
        tSamFreq[ 1]        11025
        tSamFreq[ 2]        12000
        tSamFreq[ 3]        16000
        tSamFreq[ 4]        22050
        tSamFreq[ 5]        24000
        tSamFreq[ 6]        32000
        tSamFreq[ 7]        44100
        tSamFreq[ 8]        48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00c0  1x 192 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x01
            Sampling Frequency
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.01
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     208
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      2
Device Status:     0x0000
  (Bus Powered)

[-- Attachment #3: report_descriptor.txt --]
[-- Type: text/plain, Size: 1690 bytes --]

report descriptor (size 208, read 208) =  
06 00 ff 09 01 a1 01 75 08 26 80 00 15 00 09 01 85 01 95 05 82 02 01 09 01 85 02 
95 09 82 02 01 09 01 85 03 95 0d 82 02 01 09 01 85 04 95 11 82 02 01 09 01 85 05 
95 19 82 02 01 09 01 85 06 95 31 82 02 01 09 01 85 07 95 5f 82 02 01 09 01 85 08 
95 c1 82 02 01 09 01 85 09 96 01 01 82 02 01 09 01 85 0a 96 81 01 82 02 01 09 01 
85 0b 96 01 02 82 02 01 09 01 85 0c 96 ff 02 82 02 01 09 01 85 0d 95 05 92 02 01 
09 01 85 0e 95 09 92 02 01 09 01 85 0f 95 0d 92 02 01 09 01 85 10 95 11 92 02 01 
09 01 85 11 95 19 92 02 01 09 01 85 12 95 31 92 02 01 09 01 85 13 95 5f 92 02 01 
09 01 85 14 95 c1 92 02 01 09 01 85 15 95 ff 92 02 01 c0

=====>[IPOD HID ]detailed :
 06 00 ff  //vendor defined usage page
 09 01 	   //vendor usage 1 
 a1 01	   //collection applicator
 75 08	   //report size
 26 80 00  //logical maximum
 15 00 	   //logical minimum
 //vendor usage -id   (2 bytes ) , report id (2 bytes ) ,  report count (2/3 bytes ) , i/p or o/p report (3 bytes ) 
 09 01 85 01 95 05 82 02 01 
 09 01 85 02 95 09 82 02 01 
 09 01 85 03 95 0d 82 02 01 
 09 01 85 04 95 11 82 02 01 
 09 01 85 05 95 19 82 02 01 
 09 01 85 06 95 31 82 02 01 
 09 01 85 07 95 5f 82 02 01 
 09 01 85 08 95 c1 82 02 01 
 09 01 85 09 96 01 01 82 02 01 
 09 01 85 0a 96 81 01 82 02 01 
 09 01 85 0b 96 01 02 82 02 01 
 09 01 85 0c 96 ff 02 82 02 01 
 09 01 85 0d 95 05 92 02 01
 09 01 85 0e 95 09 92 02 01 
 09 01 85 0f 95 0d 92 02 01 
 09 01 85 10 95 11 92 02 01 
 09 01 85 11 95 19 92 02 01 
 09 01 85 12 95 31 92 02 01 
 09 01 85 13 95 5f 92 02 01 
 09 01 85 14 95 c1 92 02 01 
 09 01 85 15 95 ff 92 02 01 
 
 c0 //end of collection 

Re: Report ID problem with HID-RAW interface usage

[Alan Ott]

On 07/02/2010 02:46 AM, Amit Nagal wrote:
>> 1. Your device has lots of reports, which all take the same type of data.
>>      
> Yes . the device has lots of inputs and output reports .
> the report values are<command>  <  response>  only .
>
>    
>> 2. Each report differs _only_ in its length, but the data is the same. For
>> example:
>>         1. If you want to send 5 bytes to the device, you use report 1, which
>> is 5 bytes long
>>         2. If you want to send 10 bytes to the device, you use report 2,
>> which is 10 bytes long.
>>         3. if you want to send 20 bytes to the device, you use report 3,
>> which is 20 bytes long.
>>         etc.
>>      
> Yes. exactly . data  payload len is the defining parameter to
> determine the report N to use .
>    

I'm going to challenge this. I looked at the report descriptor you 
attached, and I don't think it really works the way you think it does. 
What it looks like to me is separate reports expecting separate data, 
not a bunch of reports all expecting the same data but of different 
lengths. What you describe would be fairly non-standard, IMO.

What I would suggest for the short-term is this:
With the device you have, send data based on the HID descriptor you 
attached to the last email. I mean manually. In the case of your 
descriptor: if the report length you want to send is <= 5, use report 1; 
If it's <= 9, use report 2; if it's <= 13, use report 3; if it's <= 17, 
use report 4; if it's <= 25, use report 5, etc.

This will allow you to say for sure that it works the way you think it 
does. If it does, then you're right, (and I'm wrong :) ). I'm betting 
though, that it won't, and that each report is expecting different types 
of data than all the other reports.

Does this sound like a reasonable approach to the rest of you guys?

Alan.



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Report ID problem with HID-RAW interface usage

[Amit Nagal]

> I'm going to challenge this. I looked at the report descriptor you attached,
> and I don't think it really works the way you think it does. What it looks
> like to me is separate reports expecting separate data, not a bunch of
> reports all expecting the same data but of different lengths. What you
> describe would be fairly non-standard, IMO.
>


Sorry , i did not get what is meant by "a bunch of reports all
expecting same data
but of different lengths " . what is the meaning of this phrase "same data"  .

ya i agree if the device supports separate reports ,
theoretically each one should be there to serve separate data .
otherwise a device can define a report of max size N and all transactions
can take place with it .
but if a device support only one report of max size N
the drawback is that even to send  a very small report data (say 4-5 bytes ) ,
we have to use max size N report always , which may waste considerable
bandwidth .

Now in my case yes mostly different reports carry different data only .
as i told previously , the payload protocol is in the form  <command >
<response >.

by this i mean let say if i want to fetch ipod root folder entries
(filenames ),
i will send a command for that in a output report and device will send
root folder entries
in input reports .

so different payload commands are send over different reports only .

But again , the defining parameter that a report N should be used is
data payload len only . so if 2 payload commands have
same size , both can be send using same report ID .
and this thing is already working for me  .

> What I would suggest for the short-term is this:
> With the device you have, send data based on the HID descriptor you attached
> to the last email. I mean manually. In the case of your descriptor: if the
> report length you want to send is <= 5, use report 1; If it's <= 9, use
> report 2; if it's <= 13, use report 3; if it's <= 17, use report 4; if it's
> <= 25, use report 5, etc.
>

Yes , this approach is already working for me .
with the above mentioned approch ( <= 5 use report 1 , <=9  use report 2) and
using hidraw interface  , i am able to transact a few basic payload
commands with the device .
infact even the device is sending different payload command <Responses >
using the same < Report ID > .

May be i am wrong , due to lack of documentation regarding the
presence of different report ID ,
but i am able to transact with the device using the above mentioned
approach of sending
payload data in  a report whose size is >= data payload len .

if desired , i can send dmesg logs also depicting the same .

Thanx & Regards
Amit Nagal
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] HID: Send Report ID when numbered reports are sent over the control endpoint.

[Jiri Kosina]

On Wed, 30 Jun 2010, Alan Ott wrote:

> The Report ID wasn't sent as part of the payload for reports which were sent
> over the control endpoint. This is required by section 8.1 of the HID spec.

We already have a8ab5d58b0238b8199cc699b8dff7c5e1da24138 commit in Linus' 
tree, so I'll take this for .35 still, thanks a lot for fixing it Alan.

> 
> Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
> ---
>  drivers/hid/usbhid/hid-core.c |   13 ++++++++++---
>  1 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index deef816..1697687 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -854,14 +854,21 @@ static int usbhid_output_raw_report(struct hid_device *hid, __u8 *buf, size_t co
>  				ret++;
>  		}
>  	} else {
> +		int skipped_report_id = 0;
> +		if (buf[0] == 0x0) {
> +			/* Don't send the Report ID */
> +			buf++;
> +			count--;
> +			skipped_report_id = 1;
> +		}
>  		ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
>  			HID_REQ_SET_REPORT,
>  			USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
>  			((report_type + 1) << 8) | *buf,
> -			interface->desc.bInterfaceNumber, buf + 1, count - 1,
> +			interface->desc.bInterfaceNumber, buf, count,
>  			USB_CTRL_SET_TIMEOUT);
> -		/* count also the report id */
> -		if (ret > 0)
> +		/* count also the report id, if this was a numbered report. */
> +		if (ret > 0 && skipped_report_id)
>  			ret++;
>  	}

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html