So I did found a nice 7″ Display for my Windows 10 IoT Raspberry Pi (see my precedent post for the full story).
Ok, the display works. However, how about the touch functionality?
Here is the connection schema:
When attached to the USB port, the system fails to recognize the device. Too bad! I thought it was a sort of mouse that just send a clicked event with the screen coordinate of the touch.
I decided to replace the Raspberry card with my Surface Pro 1 to have better control and check the touch to USB controller functionality.
So long so good, but what about our Raspberry Pi 2? I can’t install an x86 driver on it, because it surely wouldn’t work on an ARM architecture!
I decided to investigate on the issue, and I started learning about drivers from scratch. Here is the learning path I’ve followed:
- WinHEC Shenzhen 2015 keynote by Don Box: Developing for the Windows 10 Device Platform
Getting started with Windows drivers (this is the order I suggest):
Universal Serial Bus (on MSDN):
The USB specifications (on USB Implementers Forum web site):
The short story is that Windows 10 introduce a new driver model, called Universal Driver, and there are many ways to avoid building a new driver from scratch. Moreover, a simple HID device should be automatically managed by the PnP (Plug ‘n play) system using one of the predefined USB drivers already made by Microsoft and available also in the Raspberry Pi version of Windows 10 IoT.
To have a better understanding of why the PnP system was not able to handle the device I followed the instructions to install WDK 10 on my Surface Pro 1 machine. Is worth noting that the WDK installation process install also the Windows Debugger Tools.
Finally, I uninstalled the touch device driver previously installed, launched the USB View utility (part of the Windows Debugger Tools) and connected the “touch to usb” device:
As you can see, the device is in the list (at Port 2) and the information exchange completed. Note that:
- The PnP system couldn’t load a driver so we don’t have an open connection after the initial data exchange (no open pipes!);
- The Device Class is 0x00 (and this is ok for a HID device, see below);
- The idVendor and the idProduct are defined (we’ll use this info for our “USBTest” Universal Windows App, more on this on next post);
- The Interface Class is 0xFF (and this is the problem, because it should be 0x03);
From the USB Core Specification documentation, we know that the class code information identify a device’s functionality and that PnP use that code to load a device driver based on that functionality. On some device (and HID devices follow this rule) the device’s functionality is identified by the interface code, and in this case the device class has to be 0x00.
From the Device Class Definition for HID 1.11 documentation, we know that these devices always have a class code of 0x00 and an interface code of 0x03. In addition, HID devices have a limited use of the subclass code. For a non-bootable device, the subclass is always 0x00.
So the main problem of the “touch to USB” device is that it declares an interface class of 0xFF that is not the expected value and the PnP system do not recognize it as a HID device and cannot find a default driver for it.
On next post, we will develop a simple Universal Windows App to try to connect with the “touch to Usb” device using the Windows 10 core API (Windows.Devices.Usb namespace). This will not solve our problem but will help us better understand how to deal with that, testing some assumption about the device. I want to check if I’ll be able to get touch events and the associated coordinates.
While waiting for the next episode, you can dig on the suggested documentation.