Oct 24, 2010
Oct 14, 2010
Oct 7, 2010
- Create 3 new classes for readWrite form. They are HID(), win32Keyboard() and handler()
- Integrate the classes into one.
- Spot out the correct process name of the foreground process, then send some hard-coded byte values to the device
- 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.
- Create an ArrayList to store all key pressed first and released all of them at once.
- Make our process running in background. Reference:
- Optimize the program, maybe by minimizing the code size and introducing some algorithms.
- Start debugging. Finding any possible bugs.
- Get URL from Hwnd, have to try.
- Find a way to register hot-key in windows
Oct 4, 2010
- 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.
- Integrate the getForegroundProcess program with this library.
- Figure out what should be sent to the widget to identify current running process.
- I forgot to change the flags and control type respectively.
- 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.
- 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.
- 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)
- Make reference to genericHID.cs and its author. It gives definition of each winAPI function useful for our HID class.
- Also acknowledge to author of the UseHIDSample.cs
Oct 2, 2010
Sep 27, 2010
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Understand how to write an appropriate report so that it can be written from linux to windows successfully.
- Create the Virtual Keyboard Application with C#. Ask MF if the programs should be installed as an apps on Windows or not.
- Start GUI side on friendlyarm.
Sep 23, 2010
- dnw.exe connect USB to PC, driver is downloaded from friendlyArm.net
- hyperterminal and COMport
- build kernel, type make zImage
- open hyperterm, press k
- send file using dnw
- on hyperterm, press b
- attach again the USB
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).