Can now communicate between gadgets and Windows

Three days for the investigation. I have googled a lot and most of the results are not reasonable. I have borrowed a book from the University Library, called

USB COMPLETE

Surprisingly, it is written by Jan Axelson which I have found his website useful before... (See the entry before, I have added his webpage for reference) Chapter 11, 12, 13 were all about the HID device.

Notes jot on these days (the weekends)

1. Windows keeps polling the HID keyboard device. This is why we cannot use the generic Winodws API to help us writing report to the gadget device. Indeed, we can try creating a composite device, that is to combine both keyboard and an USB pipe (can be any HID device that not recognized as a system device). This way, windows handles all our key sent and we do have to make a customized program ourselves. To do this, we may have to modify linux device driver code located at: /linux-2.6.35/drivers/usb/gadget/ There are some codes stating the device descriptors. We found a file called autoepdescriptor. However, exploiting it will be not easy.
2. Then we stick to a "joystick" approach. The joystick can also be recognized automatically by windows. Unfortunately, at first we enumerate the board as a joystick, the test program failed to send report to our device. We doubt that if this may be due to the absence of the OUT endpoint.
3. On the day before mid-autumn festival, I take the board from MF and start investigating the possibility of opening the pipe. I crashed the file system and recovered it following some steps.
4. Studying the possibility of adding some output report to the keyboard descriptor, but it fails as usual. One of the M$ document states that a way to make a "multi-functional" keyboard can be done by adding one more collection to the hid descriptor, but it is also not working. I doubt if the HID gadget device sticks to only 1 interrupt endpoint, which is by default 0x81 and that is why we cannot write report to the endpoint. Jan, the writer of the book, suggested that we can send report to the keyboard only by the way of writing feature report. I start trying to figure out why.
5. Reading from the book as well as the pdf file from usb.org, I found that there can be only one way to send report to the interrupt IN endpoint. That is through having a control request. I also discovered that indeed the feature report is sent in the way of control transfer (p.328; p.321) when the OUT endpoint is absent. Then I start to enumerate the keyboard with the feature report descriptor. Certainly, it did not work.
6. Googling from the web, I saw someone suggests that we can indeed make our customized, or called vendor defined HID. I saw some code from the net. One of them can successfully be implemented on our board. In the past when the HID report descriptor were written wrongly, windows would say "Cannot recognize the device". This time the device manager showed me that one INPUT DEVICE and HID COMPLIANT was installed. Since that device is enumerated with a feature report descriptor, I cannot find the way to send things to the board. Then I changed the report descriptor 0xB1 to 0x91 and start the test_hid program. Things can be sent from Windows to the board by calling winAPI (WriteFile) and the generic (Read on linux). However, it is hard to send things from the device to Windows since I mess up the format inside the report. I tried refer to the book to see what each field means and make my own vendor defined HID.
7. I found important information from the book, ch12, starting from p.370.
   [Usage Page] The upper 16 bits is shared as a global item and the lower 16 bits is used to identify local item. (p.370)...
   That is why the keyboard is recognized as a keyboard through its report descriptor. I modified the Usage page and each Usage Item to see if the device is still working. It can be recognized by Windows, without any changes of other descriptor. Then I started the test program on hyper terminal (Though, we have to study further the format of the report). The typed code can be sent to windows and displayed on the C# program. Similarly, the report can be written to the board from Windows.

To do list -

1. Understand how to write an appropriate report so that it can be written from linux to windows successfully.
2. Create the Virtual Keyboard Application with C#. Ask MF if the programs should be installed as an apps on Windows or not.
3. Start GUI side on friendlyarm.