Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Usage of HID over I2C Protocol to communicate with peripheral

BalajiKulkarniBalajiKulkarni Member Posts: 8

Hi All,

I need to use HID over I2C to communicate with a peripheral connected with SoC over I2C, this is the first time I am working with this protocol.

The FW present in the peripheral already supports HID over I2C protocol.

I went to the HID over I2c pages from MSDN and few examples. Based on my understanding so far, the HidD_GetHidGuid() and Setup* APIs provide the list of HID devices and device paths for each of them. HID also provides APIs to get or set an input/output/feature report using the handle open to a specific device.

Few queries for which I could not find more details on below:

  • In order to communicate with peripheral connected over I2C to SoC, the hardware resource configurations have to be provided in a namespace such as ACPI (I2C slave address, interrupt line, etc.). Under which ACPI device should I be defining these configurations if I plan to use HID over I2C user-mode application? I see the Microsoft inbox driver has _CID "PNP0C50", but not clear if there should be a separate ACPI device to be added that is needed for exchanging information with the peripheral.

  • Any other dependencies for using HID over I2C from user application that need to be taken care of?

Please share if there is any reference available related to HID over I2C for ACPI and other changes.


  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,448

    You create a unique Device in your ASL as described that describes your device. As you noted, the important thing to remember is you must supply the PNP0C50 CID.

    Specify your _CRS with the required I2CSerialBus and GpioInt specifications... and it should just work.

    You can enable ETW tracing to help debug any errors (though I personally have never done that, so.... who knows how well it works).


    Peter Viscarola

  • BalajiKulkarniBalajiKulkarni Member Posts: 8
    edited April 23

    Thanks, Peter. One follow-up query is if there is more than one ACPI device node referring to the same inbox I2C driver (PNP0C50), how will the application manage to connect to the right device instance? As I2CSerialBus and GPIO interrupt configuration will be different across peripherals while still using the HID over I2C.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,448

    What "application"?

    PNP0C50 just refers to the HID over I2C transport driver (hidi2c.sys); HID Class will retrieve the descriptors and enumerate HID devices by their top-level collections as appropriate.

    All as described here:

    Peter Viscarola

  • BalajiKulkarniBalajiKulkarni Member Posts: 8

    Sorry if my earlier question was confusing.

    I mean, if there is more than one device referring to Microsoft Inbox HIDI2C driver (HIDI2C.sys) using _CID in ACPI namespace (HID_Device1, HID_Device2, etc.) Each having individual I2C and GPIO configurations (such as Keyboard, Mouse, etc.)

    How would the user-mode application communicate the HID requests to a specific I2C instance? I am trying to understand how OS manages this internally.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,448

    The use application doesn’t get to choose which keyboard it reads input from. Plug in a second keyboard and you’ll see how this works. Either keyboard can be used. Same with the mouse.


    Peter Viscarola

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging TBD 2021 Live, Online