[Bug 220978] New: [DRM/ACPI] ASUS VivoBook TP412FA: Fn keys send unknown scancodes after resume from S4 (Hibernate) on fedora 43

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220978

            Bug ID: 220978
           Summary: [DRM/ACPI] ASUS VivoBook TP412FA: Fn keys send unknown
                    scancodes after resume from S4 (Hibernate) on fedora
                    43
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: monirloucas@gmail.com
        Regression: No

Created attachment 309191
  --> https://bugzilla.kernel.org/attachment.cgi?id=309191&action=edit
dmesg_after_resume.txt

sys_vendor: ASUSTeK COMPUTER INC.
product_name: VivoBook_ASUSLaptop TP412FA_TP412FA

**Problem Description:**
After resuming from Hibernate (S4), the function keys (Fn keys) for controlling
volume, screen brightness, and other special keys on my ASUS VivoBook TP412FA
stop working correctly.

**Analysis:**
Some keys work only after pressing the Fn key again, regardless of the Fn-lock
mode. Using `libinput debug-events`, I can see that many of these keys are
sending unknown scancodes to the kernel after resume.

Example output from `libinput debug-events` after resume:
event3   KEYBOARD_KEY                 +4294967.295s    *** (-1) pressed
^[OQ event3   KEYBOARD_KEY                 +0.153s      *** (-1) released
...
event3   KEYBOARD_KEY                 +8.366s  KEY_MUTE (113) pressed
event3   KEYBOARD_KEY                 +8.510s  KEY_MUTE (113) released
...
The `*** (-1)` entries indicate unknown scancodes, which the kernel cannot
interpret. The escape sequences like `^[OQ` are coming from the firmware/EC.
Some keys like Mute, VolumeUp, and VolumeDown are correctly identified
(KEY_MUTE, KEY_VOLUMEUP, KEY_VOLUMEDOWN), while others are not.

**Potential Cause:**
The issue appears to be related to the ACPI Embedded Controller (EC). After
hibernation, the EC is re-initialized in a way that changes the scancodes for
these special keys. The kernel lacks a specific quirk for this laptop model to
handle these changed scancodes. The system does not crash, but it fails to
interpret the key presses correctly.

This behavior is not present on Windows, likely because it includes a
manufacturer-specific driver that properly re-initializes the keyboard
controller after hibernation.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.