[RFC] Input: atkbd: HP Pavilion Gaming keyboard backlight key reports unknown scancode

[RFC] Input: atkbd: HP Pavilion Gaming keyboard backlight key reports unknown scancode

[Dinesh]

From: Dinesh <dkkhatana136@gmail.com>

Hi Dmitry,

I'm investigating support for the keyboard backlight hotkey on an HP Pavilion Gaming Laptop and would appreciate guidance on the preferred upstream implementation before preparing a patch.

System information:

  Manufacturer: HP
  Product: HP Pavilion Gaming Laptop
  Kernel: 7.0.0-28-generic

When pressing the keyboard backlight hotkey (Fn+F5), the kernel reports:

    atkbd serio0: Unknown key pressed (translated set 2, code 0xab)
    atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.

Running:

    sudo setkeycodes e02b 228

(where 228 corresponds to KEY_KBDILLUMTOGGLE)

causes the key to be reported correctly by the input subsystem.

To understand where the fix belongs, I investigated both the AT keyboard path and the HP WMI path.

Observations:

- The key generates translated Set 2 scancode e02b.
- acpi_listen reports no event when Fn+F5 is pressed.
- evtest on the HP WMI input device reports no event.
- Only the AT keyboard device receives the scancode.
- The recent hp-wmi commit "platform/x86: hp-wmi: Ignore backlight and FnLock events" (e8c597368b85) handles WMI notifications for newer HP systems, but my system does not emit those WMI events.

From my investigation, the issue appears to be that translated scancode 0xab is left as KEY_UNKNOWN by atkbd, while hp-wmi is never involved on this machine.

Before preparing a patch, I'd like to ask about the preferred upstream approach.

Would maintainers prefer:

1. Adding a generic atkbd Set 2 keymap entry mapping translated scancode 0xab to KEY_KBDILLUMTOGGLE,

or

2. Implementing this as HP-specific handling (for example via a DMI-based quirk)?

I'd appreciate guidance on which direction would be preferred.

Thank you for your time.

Best regards,
Dinesh