Oct 24, 2010


Using QT to develop the GUI interface these days

Made several versions. Now want to make it iphone like, may have to hard code the position of every icons.

GIMP is recommended for icon editing.

Oct 7, 2010

Today Schedule + some input report things

Today Finished:
  1. Create 3 new classes for readWrite form. They are HID(), win32Keyboard() and handler()
  2. Integrate the classes into one.
  3. Spot out the correct process name of the foreground process, then send some hard-coded byte values to the device
  4. Can read report from device and split it into two modes. The first is modifier and another is non-modifier. Modifier consists of 8Bits defined in HID1_11.pdf. Non-modifier somehow can be found by simple maths.
  5. Create an ArrayList to store all key pressed first and released all of them at once.
Going to implement:
  1. Make our process running in background. Reference:
  2. Optimize the program, maybe by minimizing the code size and introducing some algorithms.
  3. Start debugging. Finding any possible bugs.
  4. Get URL from Hwnd, have to try.
  5. Find a way to register hot-key in windows

The format of the HID report is vital for decoding the meaning inside the report.
Page 70 of the HID1_11.pdf which can be downloaded from the USB official website is useful.

Oct 4, 2010

Finished wrapping the HID API library with C# codes. A reading thread is responsible for reading something from the widget.

Following to do are:
  1. Study the pattern of the values returned. If I press a, b and c at the same time, the pattern becomes 00 00 04 05 06 00... If only a is pressed, it is 00 00 04 00 00 ... If only b is pressed, it is 00 00 05 00 00... We should write a "clever" function to analyze it.
  2. Integrate the getForegroundProcess program with this library.
  3. Figure out what should be sent to the widget to identify current running process.
The bugs that make the program unable to read and write data:
  1. I forgot to change the flags and control type respectively.
  2. To write something, nAccess = GENERIC_WRITE; nsharemode= nShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE; controlType= 0x02... It is similar if we want to read something.
  3. The overlapped structure is vital for ReadFile to call. It is originally a blocking call. However, we can change its behavior by feeding an overlapped structure to it. Refers to MSDN, the passage about Readfile.
Acknowledgement (HID class only) and some follow-up explanation:
  1. createFile is called with many arguments. These arguments should also be called from other winAPIs. We have to provide GUID at some points... (refer to the openDev src code in the class HID and also documentation from MSDN)
  2. Make reference to genericHID.cs and its author. It gives definition of each winAPI function useful for our HID class.
  3. Also acknowledge to author of the UseHIDSample.cs

Oct 2, 2010

using winAPI writeFile

  1. Have to check the flags, what do they mean...
  2. Have to ensure everything is sent successfully
  3. Try to lock the device, avoid other windows application sending things to it.

Sep 27, 2010

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


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.

Sep 23, 2010


  1. dnw.exe connect USB to PC, driver is downloaded from friendlyArm.net
  2. hyperterminal and COMport
  3. build kernel, type make zImage
  4. open hyperterm, press k
  5. send file using dnw
  6. on hyperterm, press b
  7. attach again the USB
Create shareFolder in vBox sudo mount -t ubuntuTmp windowsTmp
http://www.cygnal.org/ubb/Forum9/HTML/001381.html Explanation on keyboard descriptor

Why do I receive "Access denied" when attempting to access my HID?

Windows 2000 and later have exclusive read/write access to HIDs that are configured as a system keyboards or mice. An application can obtain a handle to a system keyboard or mouse by not requesting READ or WRITE access with CreateFile. Applications can then use HidD_SetFeature and HidD_GetFeature (if the device supports Feature reports).