Hi Brad,
Thanks for your message and the web link:
>http://www.frogmouth.net/hid-doco/examples/hiddev-misc/write-events.c
Unforunately the HIDIOCSREPORT ioctl will not meet the need.
Perhaps I need to be more explicit about the problem.
There is a discrepancy between the hiddev architecture and the USB
implementation on the ADU board.
(note that the ADU board conforms to USB 1.1 spec, not the original
version 1.0 spec)
****
An aside for Jeff:
Please indicate whether the following analysis matches your research
regarding the Evolution Robots platform.
****
It is important to differentiate the endpoints in this discussion.
Control in/out endpoint - always assumed present
Interrupt in endpoint - for data inbound to the PC
Interrupt out endpoint - for data outbound to the peripheral device
The interrupt out endpoint was NOT present in the USB 1.0 spec. It was
a new concept added in the USB 1.1 spec.
The HIDIOCSREPORT uses the control endpoint for output to the device.
The ADU device uses control endpoints for enumeration only.
The ADU board transmits all inbound data via the interrupt in endpoint.
The ADU board receives all outbound data via the interrupt out endpoint.
Hiddev assumes that outbound data is transmitted on the
control endpoint as evidenced by the following code snippets.
(taken from the 2.4.20 kernel source code)
The usb_hid_configure function in hid-core.c sets up the
hid->urbout as an outbound control endpoint.
FILL_CONTROL_URB(&hid->urbout, dev, usb_sndctrlpipe(dev, 0), ...
The usb_hid_configure function deliberately restricts interrupt
endpoints to input only.
if ((endpoint->bmAttributes & 3) != 3) /* Not an interrupt endpoint */
continue;
if (!(endpoint->bEndpointAddress & 0x80)) /* Not an input endpoint */
continue;
pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
FILL_INT_URB(..., pipe, ...);
When an application calls the HIDIOCSREPORT ioctl the hid_submit_out
uses the hid->urbout URB to write to the device. This results
in an attempt to output something on the **control** outbound endpoint,
whereas the ADU device is waiting for something on the **interrupt**
outbound endpoint. The ADU device expects only enumeration
messages on the control endpoint, it will not accept reports that are
written to the control endpoint.
We need the ability to write data to the interrupt out endpoint
of a hid class device (not just to the control out endpoint).
This is an extension of the functionality already in place, not a
replacement of any functionality. All of the normal enumeration,
control messages and reports must continue to operate.
Seeing as the hiddev_read function reads data from the interrupt
endpoint, I thought the logical place to write to the interrupt
endpoint would be "hiddev_write". The current hiddev_write
function returns -EINVAL so changing it should not break anything.
The HIDIOCSREPORT should continue to communicate via
the control endpoint, while the hiddev_write uses the interrupt
endpoint.
The "data" is an opaque string of bytes, it is neither a
control message nor a report as defined in the USB spec.
It is just a data-load to be delivered to the device. (Similar to
the buffer in the existing hiddev_read.)
NOTE: The ADU board uses a Microchip PIC processor that has USB
support built in as a combination of firmware and silicon
circuitry. I would really like to see a generic solution so that
all similarly designed HID class devices could use their
interrupt out endpoints. (ie. the Ontrak ADU board, the Evolution
Robot, the Labjack board, etcetera).
I hope that this clarifies the problems we are having with
hiddev and the ADU board.
Thanks for your attention,
John Homppi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
