Sep 19, 2010

Mid September

We have stuck in the process of how windows sends message to HID device. On this stage, we successfully enumerate the mini2440 as a HID keyboard to Windows. The thing left was sending the right HID report to the device.

It seems that windows does not allow us to send any HID report to the keyboard, any HID device other than keyboard or mouse, it will be fine. There are many sites talking about this. winAPI provides two basic function for developers to send the HID reports to the target USB HID device. They are called, (quoted from MSDN, http://msdn.microsoft.com/en-us/library/ff542417(v=VS.85).aspx)

  1. ReadFile(...), WriteFile(...)
  2. HID_setXXX(...), HID_getXXX(...)
They are quoted without test, hopefully tomorrow we will test it on mini2440. Several useful references were quoted. http://courses.cs.tau.ac.il/embedded/projects/fall2009/HID-Host/ This site shows how they use win32 API to make a customized device.

For generic USB HID concept, a PDF file is downloaded and stored in the vBox. From this point of view, we knew that the interface is a collection of endpoints. The endpoints work as accepting or sending control messages to or from the host. Tommorow we will try making one more interface or one endpoint as a port for win32 to send the command.

Quoted from offical Linux Gadget HID driver:

At this writing there are several public "gadget drivers", each implementing a single common USB function so it will work with virtually any USB peripheral controller. (Drivers for composite gadgets, or for audio/video drivers requiring isochronous transfers, would not be able to work on at least some controller hardware. The gadget API does support such drivers.) You should plan on testing these in conjunction with the controller driver and system board you'll be using.

  • Gadget Zero ... is essential for controller driver testing. It provides two configurations: one for bulk traffic source/sink, and another for bulk traffic loopback. On the device side it helps verify that the driver stack pass USB-IF and other tests (needed for at least USB branding). On the host side it helps test the USB stack, such as the Linux-USB HCDs and usbcore. If built as a module, start it by modprobe g_zero; no other initialization is needed. (Use the autoresume=N module parameter to make it try triggering remote wakeup N seconds after it's suspended.)
  • ………………………………………..
  • GadgetFS ... since not every developer wants to program in the kernel, or rely specifically on the Linux kernel APIs, a user mode API is available. An example user mode driver is usb.c. (It also needs usbstring.c and usbstring.h.) Notice how the device is initialized by writing its configuration and device descriptors to a file (such as /dev/gadget/$CHIP), and how the endpoints are initialized in similar ways (writing descriptors to /dev/gadget/$ENDPOINT). After initializing them, just read or write to the files to transfer data; or to handle events including control requests to retrieve string descriptors, configure alternate settings, and implement class or vendor requests. On Linux 2.6 AIO (Async I/O) support is available, helping user mode drivers avoid i/o latencies and letting them stream data as quickly as in-kernel drivers can stream it. Note that user mode gadget drivers do not necesarily need to be licensed according to the GPL.
Quoted from M$
It isn't possible to open a handle to a mouse or keyboard collection because the system input thread has opened these devices exclusively. Furthermore, these devices don't appear in the enumeration of the HID interface GUID. (HIDCLASS doesn't advertise the HID interface GUID for keyboard and mice so as to prevent some random user-mode program from opening those devices before the system's own raw input thread can do so.) It does you no good to register a private interface GUID for your device because HIDCLASS will fail an IRP_MJ_CREATE directed to the main device object. Consequently, there is no way to communicate with a custom mouse or keyboard driver using standard methods.


Useful website:

No comments:

Post a Comment