none
HID-compliant touch screen packet data structure RRS feed

  • Question

  • What is the data structure of HID-compliant touch screen packets?

    No.     Time           Source                Destination           Protocol Length Info
         22 5.051205       3.6.1                 host                  USB      38     URB_INTERRUPT in


    Frame 22: 38 bytes on wire (304 bits), 38 bytes captured (304 bits)
    USB URB
        [Source: 3.6.1]
        [Destination: host]
        USBPcap pseudoheader length: 27
        IRP ID: 0xffffe28b162b7770
        IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
        URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)
        IRP information: 0x01, Direction: PDO -> FDO
        URB bus id: 3
        Device address: 6
        Endpoint: 0x81, Direction: IN
        URB transfer type: URB_INTERRUPT (0x01)
        Packet Data Length: 11
        [bInterfaceClass: HID (0x03)]
    Leftover Capture Data: 010100124c003700014c01

    All touch screen connected to Windows 10 all show the 11 bytes of data, same as "Leftover Capture Data".  Out of the 11 bytes, there must me X-coordinate and Y-coordinate, but need to know the exact data structure.

    Where would this data structure be defined?

    Tuesday, February 6, 2018 9:47 PM

Answers

  • See the HID specification here. To decode a HID stream, you need the device's report descriptor (also defined in the HID spec). What is the larger problem that you're trying to solve?

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Wednesday, February 7, 2018 2:47 AM
    Moderator

All replies

  • See the HID specification here. To decode a HID stream, you need the device's report descriptor (also defined in the HID spec). What is the larger problem that you're trying to solve?

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Wednesday, February 7, 2018 2:47 AM
    Moderator
  • The larger picture is that I have touch panel that I have created, but this touch panel is an input device to the PC, but the unique piece is that it is an output device to the user as well.

    I want to design a driver where I can route the packets to Windows natively as a "HID-compliant touch screen", but I'd also like to funnel the input to a different piece of software (either application or a filter driver) and generate output to a user.

    The biggest issue is determining how to navigate the "HID Report Descriptor" to come up with the data structure for it so that I can use it. (Please see attachment)

    Wednesday, February 7, 2018 5:56 PM
  • I just wrote a driver like this for a client last month. If you write a lower class filter on USBHID, then you can see the HID reports on their way to the HID class driver. At that point, you have full control over the HID report and you can fork the stream to also send the reports to an application, if you like.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Wednesday, February 7, 2018 6:42 PM
    Moderator
  • I want to design a driver where I can route the packets to Windows natively as a "HID-compliant touch screen", but I'd also like to funnel the input to a different piece of software (either application or a filter driver) and generate output to a user.

    So, do you want actually to send something else to the host besides of your touch data? If so, just create another HID collection and give it a different report ID. For example, your touch data will be report ID #1 and the other stuff - report id #2. These reports will go out a single endpoint. Or, make your device multifunction, so that each kind of data is contained in its own interface, one is HID and another also HID or something else. Each such function will need a separate endpoint.  Unfortunately all this HID descriptor stuff is complicated and takes some time to find info and digest it. With both approaches, you don't write any custom driver; the built-in Windows HID driver takes care of all functions.

    -- pa


    • Edited by Pavel A Wednesday, February 7, 2018 10:17 PM
    Wednesday, February 7, 2018 10:15 PM
  • what is inferred in Pavel's response is that if you conform to the HID class spec, you don't have to write a driver at all. you can expose this second stream of data as either a new HID top level collection or as "raw" usb data (probably on a bulk endpoint).  if you choose the "raw" data choice then you can use winusb.sys as the driver and just have an application read it.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, February 7, 2018 11:26 PM
  • Yes, your comment "stuff is complicated and takes some time to find info and digest it", I find to be true.

    The closest I've come to determining how to understand the "HID Report Descriptor" is at the link below and it does a great job except it is already outdated because USB has changed:

    http://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/

    I will need to look at the details of the bytes of data to verify because the Wireshark plugin I am using to view it might not be correct.

    Thank you for the suggestion.

    Thursday, February 8, 2018 1:51 AM
  • http://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/

    Yes, I've found this very helpful too.

    - pa

    Thursday, February 8, 2018 3:17 PM
  • I was able to find some open source software that converts a HID descriptor report into 'C language' data structures.

    Thanks to everyone for your help.

    Friday, February 16, 2018 7:16 PM