Page MenuHomeFreeBSD

Separate HID support from USB subsystem and import sysutils/iichid into the base.
AbandonedPublic

Authored by wulf on Dec 26 2020, 7:09 PM.

Details

Summary

This patch is an attempt to reduce (hopefully terminate) gap with Open/NetBSD we have in HID support for decades.

It does following:

  1. Move the generic HID functionality out of usbhid.h and usbhid.c into new subsystem under dev/hid directory and make it separate kernel module. Open/NetBSD already did it 5 years ago. This requires including of extra device hid line into each kernel config supporting HID devices.
  2. Create an abstract HID interface that provides transport independent access to HID capabilities and functions through the device tree. Kobj-based HID interface can be found in hid_if.m
  3. Add I2C transport backend iichid.c which implements hid_if.m methods for iicbus(4) child devices. This backend is sufficiently based on prior Marc Priggemeyer's work: https://reviews.freebsd.org/D16698
  4. Add USB transport backend usbhid.c which implements hid_if.m methods for usbus(4) child devices. This one is derived from uhid(4) driver.
  5. Implement hidbus - driver which provides support for multiple HID driver attachments to single HID transport backend. This ability existed in Net/OpenBSD from the day 0 (uhidev and ihidev drivers) but has never been ported to FreeBSD. Unlike Net/OpenBSD we do not use report number alone to distinct report source but we follow MS way and use a top level collection (TLC) usage that report belongs to for doing that.
  6. Port of some existing HID drivers, namely ukbd(4) and wmt(4) to the new HID infrastructure. That adds support for I2C keyboards (not tested yet) and I2C MT touchpads/touchscreens.
  7. Create generic HID item value to evdev event conversion engine called hidmap that makes possible to write HID drivers in mostly declarative way with defining of translation tables.
  8. Add a bunch of front hidmap-based drivers written by me:
    • hms - HID mouse driver.
    • hcons - Consumer page AKA Multimedia keys driver.
    • hsctrl - System Controls page (Power/Sleep keys) driver.
    • ps4dshock - Sony DualShock 4 gamepad driver.
  9. Add a bunch of front hidmap-based drivers submitted by Greg V:
    • hpen - Generic / MS Windows compatible HID pen tablet driver.
    • hgame - Game controller and joystick driver.
    • xb360gp - driver for Xbox360-compatible game controllers.
  10. Add hidraw(4) - driver for raw access to HID devices resembling uhid(4). Unlike uhid(4) it allows access to devices which was claimed by other drivers and supports both uhid and Linux hidraw interfaces.
  11. Quirk module and devmatch hint support were mostly copied from USB subsystem.

Also, this adds following kernel options:
HID_DEBUG - enable debug msgs
IICHID_SAMPLING - Enable support for a sampling mode as interrupt resource acquisition is not always possible in a case of GPIO interrupts.
IICHID_DEBUG - Enable debug output.
USBHID_ENABLED -Prefer usbhid to other USB drivers
HIDRAW_MAKE_UHID_ALIAS - installs /dev/uhid# alias to hidraw character device. Has a side effect of renaming traditional uhid(4) driver to hidraw.

As usbhid(4) is unfriendly to other existing USB HID drivers, it is disabled by default for now with both lowering probe priority and removing of MODULE_PNP_INFO linker hints. Specifying of USBHID_ENABLED option in kernel config should do the opposite thing.

Supposed commit history with some commit descriptions can be found here:
https://github.com/wulf7/freebsd/compare/main...wulf7:iichid

Test Plan

Run it (or sysutils/iichid) for some time.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

wulf requested review of this revision.Dec 26 2020, 7:09 PM
sys/amd64/conf/GENERIC
389–391

Why are these ones here, commented out?

sys/amd64/conf/GENERIC
389–391

usbhid conflicts* with all existing USB HID drivers as it designed to replace most of them.

That is why it is disabled by default for now.

  • "Conflicts" means it attaches to USB device preventing existing driver to do the same.

Does this review include changes that are on your iichid branch but have their own reviews (like D27747 and D27748)?

I think this review is good for folks who want to test, but for actual review the individual changes on your branch are easier to read and reason about.

All changes have been committed.