[BUG] HID: a8a5:2255 maps vendor data to stuck brightness and mic-mute keys
From: Vn Vx
Date: Fri Jul 31 2026 - 15:43:43 EST
Hello,
A YJX-CHIP USB mouse receiver, USB ID a8a5:2255, intermittently
produces stuck brightness and microphone-mute keys on Linux.
The device is connected through its USB receiver, not through BlueZ.
The mouse works normally on Windows. On Linux, shortly after switching
the mouse on, the display can be forced continuously to maximum
brightness and the microphone can be muted.
Environment
===========
Distribution: Arch Linux
Kernel: 7.1.5-arch1-1
Architecture: x86_64
Kernel taint value after reproduction: 0
Desktop: KDE Plasma, Wayland
Driver: usbhid / hid-generic
USB device: a8a5:2255 YJX-CHIP USB Receiver
I have not yet runtime-tested a vanilla mainline kernel. Linux master
still contains the mapping described below.
Reproduction
============
1. Connect the a8a5:2255 receiver.
2. Switch the mouse off and on.
3. Repeat if necessary because the faulty state is intermittent.
4. Monitor the receiver input nodes with evtest or libinput record.
When the fault occurs, the receiver's auxiliary evdev node continuously
reports:
EV_KEY KEY_BRIGHTNESSUP value 2
I captured 802 repeats over approximately 27.28 seconds, at about
29.4 events per second. This matches the configured key-repeat period.
When the receiver was disconnected, the same input node generated
release events for:
KEY_BRIGHTNESSDOWN
KEY_BRIGHTNESSUP
KEY_MICMUTE
This auxiliary input node advertises only those three keys. Mouse
movement, buttons and scrolling are exposed through a separate input
node.
Raw HID and report descriptor
=============================
The affected composite HID interface is interface 02. Its report
descriptor is 215 bytes.
At descriptor offsets approximately 0xb8 through 0xba it declares
vendor-defined usage page 0xff01:
06 01 ff
Report ID 0xf0 carries 63 bytes of proprietary receiver data. One
captured report was:
f0 0e 00 e4 2e 00 00 00 00 ...
The non-zero proprietary fields are interpreted as usages 1, 3 and 4
from page 0xff01.
Kernel-side analysis
====================
include/linux/hid.h defines page 0xff01 as:
#define HID_UP_HPVENDOR2 0xff010000
drivers/hid/hid-input.c handles that page in the generic HID input path
without checking the USB vendor or product:
case HID_UP_HPVENDOR2:
set_bit(EV_REP, input->evbit);
switch (usage->hid & HID_USAGE) {
case 0x001: map_key_clear(KEY_MICMUTE); break;
case 0x003: map_key_clear(KEY_BRIGHTNESSDOWN); break;
case 0x004: map_key_clear(KEY_BRIGHTNESSUP); break;
default: goto ignore;
}
break;
Consequently, proprietary data from this non-HP receiver is exposed as
Linux input keys.
The brightness mappings originated in commit:
929578ab0339 ("HID: Add suport for the brightness control keys on HP keyboards")
The microphone mapping originated in commit:
08fc94733211 ("HID: input: add mic mute key on HP slim keyboard")
Those commits targeted HP or HP-bundled keyboards, but the resulting
mapping is applied globally to every HID device using vendor page
0xff01.
Workaround and validation
=========================
I installed a narrowly matched udev/libinput rule that ignores only the
a8a5:2255 auxiliary node whose key bitmap consists of brightness-down,
brightness-up and microphone-mute.
During validation, the receiver entered the faulty state again. Direct
evdev monitoring still captured 112 KEY_BRIGHTNESSUP repeats and the
raw 0xf0 report, but Plasma ignored that node. Brightness remained at
50%, the microphone remained unmuted, and normal mouse functionality
continued working.
This confirms that the desktop applications are only consumers of the
incorrect kernel input events; they are not generating them.
Possible fixes
==============
Would the preferred upstream fix be:
1. restricting HID_UP_HPVENDOR2 mappings to known HP/HP-OEM devices;
2. adding a targeted quirk for a8a5:2255; or
3. adding a device-specific input_mapping callback that ignores page
0xff01 for this receiver?
I have an untested proof-of-concept patch that skips the HP-specific
mapping for a8a5:2255. I can build and runtime-test a maintainer-approved
approach and provide hid-tools regression data.
Please let me know what additional captures or tests would be useful.
Best Regards.
A YJX-CHIP USB mouse receiver, USB ID a8a5:2255, intermittently
produces stuck brightness and microphone-mute keys on Linux.
The device is connected through its USB receiver, not through BlueZ.
The mouse works normally on Windows. On Linux, shortly after switching
the mouse on, the display can be forced continuously to maximum
brightness and the microphone can be muted.
Environment
===========
Distribution: Arch Linux
Kernel: 7.1.5-arch1-1
Architecture: x86_64
Kernel taint value after reproduction: 0
Desktop: KDE Plasma, Wayland
Driver: usbhid / hid-generic
USB device: a8a5:2255 YJX-CHIP USB Receiver
I have not yet runtime-tested a vanilla mainline kernel. Linux master
still contains the mapping described below.
Reproduction
============
1. Connect the a8a5:2255 receiver.
2. Switch the mouse off and on.
3. Repeat if necessary because the faulty state is intermittent.
4. Monitor the receiver input nodes with evtest or libinput record.
When the fault occurs, the receiver's auxiliary evdev node continuously
reports:
EV_KEY KEY_BRIGHTNESSUP value 2
I captured 802 repeats over approximately 27.28 seconds, at about
29.4 events per second. This matches the configured key-repeat period.
When the receiver was disconnected, the same input node generated
release events for:
KEY_BRIGHTNESSDOWN
KEY_BRIGHTNESSUP
KEY_MICMUTE
This auxiliary input node advertises only those three keys. Mouse
movement, buttons and scrolling are exposed through a separate input
node.
Raw HID and report descriptor
=============================
The affected composite HID interface is interface 02. Its report
descriptor is 215 bytes.
At descriptor offsets approximately 0xb8 through 0xba it declares
vendor-defined usage page 0xff01:
06 01 ff
Report ID 0xf0 carries 63 bytes of proprietary receiver data. One
captured report was:
f0 0e 00 e4 2e 00 00 00 00 ...
The non-zero proprietary fields are interpreted as usages 1, 3 and 4
from page 0xff01.
Kernel-side analysis
====================
include/linux/hid.h defines page 0xff01 as:
#define HID_UP_HPVENDOR2 0xff010000
drivers/hid/hid-input.c handles that page in the generic HID input path
without checking the USB vendor or product:
case HID_UP_HPVENDOR2:
set_bit(EV_REP, input->evbit);
switch (usage->hid & HID_USAGE) {
case 0x001: map_key_clear(KEY_MICMUTE); break;
case 0x003: map_key_clear(KEY_BRIGHTNESSDOWN); break;
case 0x004: map_key_clear(KEY_BRIGHTNESSUP); break;
default: goto ignore;
}
break;
Consequently, proprietary data from this non-HP receiver is exposed as
Linux input keys.
The brightness mappings originated in commit:
929578ab0339 ("HID: Add suport for the brightness control keys on HP keyboards")
The microphone mapping originated in commit:
08fc94733211 ("HID: input: add mic mute key on HP slim keyboard")
Those commits targeted HP or HP-bundled keyboards, but the resulting
mapping is applied globally to every HID device using vendor page
0xff01.
Workaround and validation
=========================
I installed a narrowly matched udev/libinput rule that ignores only the
a8a5:2255 auxiliary node whose key bitmap consists of brightness-down,
brightness-up and microphone-mute.
During validation, the receiver entered the faulty state again. Direct
evdev monitoring still captured 112 KEY_BRIGHTNESSUP repeats and the
raw 0xf0 report, but Plasma ignored that node. Brightness remained at
50%, the microphone remained unmuted, and normal mouse functionality
continued working.
This confirms that the desktop applications are only consumers of the
incorrect kernel input events; they are not generating them.
Possible fixes
==============
Would the preferred upstream fix be:
1. restricting HID_UP_HPVENDOR2 mappings to known HP/HP-OEM devices;
2. adding a targeted quirk for a8a5:2255; or
3. adding a device-specific input_mapping callback that ignores page
0xff01 for this receiver?
I have an untested proof-of-concept patch that skips the HP-specific
mapping for a8a5:2255. I can build and runtime-test a maintainer-approved
approach and provide hid-tools regression data.
Please let me know what additional captures or tests would be useful.
Best Regards.
Attachment:
yjx-a8a5-2255-kernel-report-attachments.tar.gz
Description: application/gzip
Attachment:
optional-additional-info-yjx-a8a5-2255-report.tar.gz
Description: application/gzip