Learning USB HID in Linux Part 1 - Basics

-
What is HID?

 HID stands for Human Interface Device. From Wikipedia: "HID is a device used by humans which takes input from humans and gives output to humans"

Examples: Joysticks, Mouse, Keyboard, Barcode Readers, volume controls on speakers/headsets

Why was HID Created?

  • Replacement of PS/2
  • Creating interface over USB and to have a generic driver for HID devices like keyboard, mice and game controllers. 
Components of HID?

  • Device: Interacts directly with human such as mouse, keyboard
  • Host: Communicates with device and receives input data from the device on actions performed by the human. Output data flows from host to device and then to human
HID was originally defined to use over USB, but now used with other transport layers like
1. Bluetooth HID
2. HID over I2C
3. HOGP (HID over GATT Protocol)

We will be discussing mainly in this series on USB HID. 

HID Terminology


Reports:
Communication in HID Happens using "Reports". Reports inform the host that something is happening on the device.
Types:
1. Input Reports: Reports from Device to Host (E.g. mouse movement, keystroke etc)
2. Output Reports: Reports from Host to Device (E.g. Turn on the Caps Lock Led)
3. Feature Reports: Reports related to configuration information


Report Descriptors: 
To understand a report from the device, you need to know what each bits/bytes significance. Report descriptor is static (hard coded array of bytes) which informs significance of each bits/bytes.
Report descriptors informs:
  • Size of the Report Packet
  • How many packets it supports
  • Purpose of each byte and bit in each packet
HID Report Descriptor is requested by a USB Host from a USB Device.
Example: Keyboard with calculator program button informs the host that the calculator buttons pressed/release state is stored as the 2nd bit in the 6th byte of the Report

Endpoints:

When a device declares itself as HID, it has to implement the following endpoints:
  • Control Endpoint (EP 0)
  • Interrupt IN Endpoint 
  • Interrupt OUT EndPoint (Optional)
Advantages of USB HID:

Enables an application to talk directly with the device without the need of vendor-supplied device drivers.

References:

 1. https://en.wikipedia.org/wiki/Human_interface_device
2. https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts

Comments

Post a Comment

Popular posts from this blog

bb.utils.contains yocto

-
Image
bb.utils.contains  is most commonly used function in Yocto. grep in poky directory returned with 696 count. $ grep -nr 'bb.utils.contains' poky/ | wc -l 696 It's definition is present in 'poky/bitbake/lib/bb/utils.py' file This function returns third argument if the second argument is subset of the first argument else returns fourth argument Let's take an example to understand this. You can see from the above screenshot, when the second argument is a subset of first argument, "present" was returned, else "notpresent" was returned We can also use bb.utils.contains inside if loop. This we can use inside a recipe. if ${@bb.utils.contains('SOMEFLAG','NEWVALUE3','true','false',d)}; then     FOO = 'HELLO' fi
Read more

Difference between RDEPENDS and DEPENDS in Yocto

-
We normally observe these two (RDEPENDS and DEPENDS) whenever we open any recipe. What should we choose when we write our own recipe. DEPENDS -> Build Time Dependency RDEPENDS -> Run Time Dependency DEPENDS: When a recipe 'A' is DEPENDS on recipe 'B'. In this case, Bitbake first builds recipe 'B' and then recipe 'A' E.g. You need 'dbus' to be built before 'wpa_supplicant'. RDEPENDS: When a recipe 'A' is RDEPENDS on recipe 'B'. In this case, Bitbake deploys 'B' on the target system when it deploys 'A'.  E.g. 'perf' RDEPENDS on 'bash' In other words, DEPENDS are those set of packages that should be available while building package, whereas RDEPENDS are set of packages that should be available during execution of the program.
Read more

PR, PN and PV Variable in Yocto

-
PN : Represents the name of the recipe. The name is usually extracted from the recipe file name. PR:  Represents the revision of the recipe. Default value for this revision is "r0". Subsequent revisions of the recipe conventionally will have "r1", "r2" and so on. PV:  Represents the version of the recipe. Normally extracted from the recipe file name. For example: ffmpeg_3.4.2.bb recipe. ${PN} : ffmpeg ${PV} : 3.4.2
Read more