It seems that more files should be fixed. See your previous patch: https://reviews.freebsd.org/D56126

In D56126#1283969, @chris.longros_gmail.com wrote:

You're right, the generic Realtek rule already covers this. I missed the USB_VENDOR match at the top of the table. Abandoning this diff.

Good point about the other 0x0bda entries too -- I can submit a cleanup diff to drop those if you'd like.

Other Realtek entries are inherited from Linux. I think we can drop them.

Realtek devices are handled by generic Realtek rule. Does it work for you?

Alder Lake system is not needed

LGTM. Could you test Intel BT identify patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290639 ?

Radio button can not be correctly handled my hidmap. MS does strange things here assuming every event in report as a keypress.

It will trigger enumeration value ‘S76_CTRL_MAX’ not specifically handled in switch if -Wswitch option is passed to compiler.
From [1]:

-Wswitch

Warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration. (The presence of a default label prevents this warning.) case labels that do not correspond to enumerators also provoke warnings when this option is used, unless the enumeration is marked with the flag_enum attribute. This warning is enabled by -Wall.

Obviously case S76_CTRL_MAX is not generally handled in switch() statements.

I dislike this idea.
The sysctl sys.class.drm.card0-DP-1 path matches Linux while sysctl sys.device.drmn1.card0.card0-DP-1 not

In D55694#1274837, @pouria wrote:

The keyboard_color has full RGB coverage and accept 24-bit value as its input, so I don't think registering it in backlight be a good idea.

Adding of EVDEV interface would be good idea too. See sys/dev/acpi_support/acpi_asus_wmi.c again

In D55694#1274782, @pouria wrote:

could you take another look at the code?

We have backlight(9) interface since FreeBSD 13

LGTM

Fix braino. size->count

Update page table in chunks having faked page array fit in malloc zone

Not needed after D54225 changes

D54225 uses pmap_qenter() now

Use pmap_qenter() instead homegrown pmap_qmapdev_attr()

s/lkpi_/linuxkpi_/
Add actual arch name to panic message

s/linux_/lkpi_/ in function names

This should be joined with D54223

This should be joined with D54226

It also adds support for compound HID like keyboard and mice sharing the same USB interface

In D53931#1233481, @wulf wrote:

Old uhid(4) features now are provided with hidraw(4) driver, Note that character device path now changed from /dev/uhid# to /dev/hidraw#. To use old path recompile kernel with option HIDRAW_MAKE_UHID_ALIAS added to kernel config. Hidraw(4) is not loaded by default. kldload hidraw.ko is required.

In D53931#1232324, @emaste wrote:

@wulf can we add a sentence or two about any user-facing impact, config changes, etc.? For most people it will be a no-op.

What about:

• peripherals other than keyboard and mouse, like game controllers?

usbhid enables support for following devices:

• absolute mices for virtualized environments in hms(4)
• digitizers and pens in hpen(4)
• special keyboard function keys (volume, brightness, etc.) in hcons(4) and hsctrl(4)
• game controllers. XBox360 and PS4 gamepads in xb360gp(4) and ps4dshock(4) and generic devices in hgame(4)
• raw HID devices in hidraw(4)

• FIDO keys handled by u2f

Should work like before neither device name nor protocol has been changed

• Interaction with HID devices on other than USB

Not expected

That effectively reverts commit 548d3aa856a9

That effectively reverts commit 548d3aa856a9 (https://github.com/freebsd/freebsd-src/commit/548d3aa856a97f4483554beceeb57fa9ba0ff913) and thus will broke some rare devices.