Re: uhid(4) and report structures

From: Alexander Motin <mav_at_FreeBSD.org>
Date: Tue, 15 Nov 2011 23:34:39 +0200
On 15.11.2011 22:54, Marcus von Appen wrote:
> On, Tue Nov 15, 2011, Alexander Motin wrote:
>
>> On 15.11.2011 21:29, Marcus von Appen wrote:
>>> I wonder, if I am correct with my assumption that the usb_ctl_report*
>>> structures mentioned in uhid(4) have to be defined and created by the
>>> code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(),
>>> ... calls.
>>>
>>> In FreeBSD<   800063 we defined them in the header files of the USB
>>> subsystem. After the rewrite those struct definitions vanished.  Will
>>> the USB_ macros mentioned in uhid(4) "just" return a byte sequence
>>> (that's what I understand from the UHID specification) so that code,
>>> which uses those calls, can implement its own struct container for the
>>> information retrieved?
>>>
>>> Thanks for shedding some light on this. In case i am correct with what I
>>> wrote above, it might make sense to mention it in uhid(4).
>>
>> In new USB stack these calls use struct usb_gen_descriptor argument.
>> Difficult to say why it was done, but it was. To hide that I've recently
>> added two wrapper functions to the libusbhid in HEAD: hid_get_report()
>> and hid_set_report().
>
> So the man page is currently not up to date and can - at least for now -
> be assumed to be wrong?
> To get the mappings correct, which fields would I have to use from
> usb_gen_descriptor? Earlier we had:
>
> struct usb_ctl_report {
>      int     ucr_report;
>      u_char  ucr_data[1024];
> };
>
> The mapping might be:
>
>      usb_gen_descriptor.ugd_data == usb_ctl_report.ucr_data
>      usb_gen_descriptor.ugd_report_type == usb_ctl_report.ucr_report
>
> Is that correct? Also, ugd_data is of variable size with ugd_actlen
> indicating the size of the ugd_data buffer?

Here is usage example:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libusbhid/data.c.diff?r1=1.9;r2=1.10;f=h

-- 
Alexander Motin
Received on Tue Nov 15 2011 - 20:34:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC