Usage of HID over I2C Protocol to communicate with peripheral

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.

You create a unique Device in your ASL as described https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/plug-and-play-support-and-power-management[here](https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/plug-and-play-support-and-power-management) 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

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.

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:

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.

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