SL4A FN keys not working

I updated recently and found that the when I enable the fn key my keyboard no longer lets me type normally and pressing the function keys do not work eg F5 to reload browser tab. It will also lock up the kde desktop (unable to interact with the task bar).

I am running 6.15.3-1.surface.fc42.x86_6 on Fedora 42 KDE Spin

Heres a list of outputs from showkey -a. The keys seem to be mapped right so my guess is its something to do with the FN key?

^[OP     27 0033 0x1b
         79 0117 0x4f
         80 0120 0x50
^[OQ     27 0033 0x1b
         79 0117 0x4f
         81 0121 0x51
^[OR     27 0033 0x1b
         79 0117 0x4f
         82 0122 0x52
^[OS     27 0033 0x1b
         79 0117 0x4f
         83 0123 0x53
^[[15~   27 0033 0x1b
         91 0133 0x5b
         49 0061 0x31
         53 0065 0x35
        126 0176 0x7e
^[[17~   27 0033 0x1b
         91 0133 0x5b
         49 0061 0x31
         55 0067 0x37
        126 0176 0x7e
^[[18~   27 0033 0x1b
         91 0133 0x5b
         49 0061 0x31
         56 0070 0x38
        126 0176 0x7e
^[[19~   27 0033 0x1b
         91 0133 0x5b
         49 0061 0x31
         57 0071 0x39
        126 0176 0x7e
^[[20~   27 0033 0x1b
         91 0133 0x5b
         50 0062 0x32
         48 0060 0x30
        126 0176 0x7e
^[[21~   27 0033 0x1b
         91 0133 0x5b
         50 0062 0x32
         49 0061 0x31
        126 0176 0x7e
^[[23~   27 0033 0x1b
         91 0133 0x5b
         50 0062 0x32
         51 0063 0x33
        126 0176 0x7e
^[[24~   27 0033 0x1b
         91 0133 0x5b
         50 0062 0x32
         52 0064 0x34
        126 0176 0x7e

Also experiencing this on a fresh install. The behavior is exactly like that described in #1719 but this is on a surface laptop 4 with built-in keyboard using Plasma on Arch..

I've had this for months, and I could never figure out what going on with keyboard and mouse focus.

I'm using a SL4A.

I was suspending the laptop by closing the screen and this would resolve it.

sudo modprobe -r surface_hid && sudo modprobe surface_hid

Is working around it also. I'll keep digging.

@RichardODonoghue

@RichardODonoghue and @leinaht are you both using KDE on wayland? This seems to be the only combination that triggers this bug for me.

Add patch to filter BTN_0 (FN key) events on Surface devices

I've identified the root cause and created a working fix for this issue.

Root Cause

The Surface Aggregator Module firmware incorrectly reports the FN key as BTN_0 (button 256) through runtime HID events. This button can get stuck in pressed state, flooding the input system with repeated press events (~every 34ms), which breaks input focus tracking in KWin Wayland.

Solution

Created a new HID driver (hid-surface.c) that filters BTN_0 events using the event callback. This prevents BTN_0 from reaching the input subsystem while allowing all other keyboard/touchpad functionality to work normally.

Testing Results

Hardware: Surface Laptop 4 AMD (Ryzen 5)
OS: Arch Linux, Kernel 6.16.9-arch1-1-surface
Desktop: KDE Plasma 6.4.5 Wayland

After applying the fix:

✅ FN+Volume works correctly
✅ FN+Brightness works correctly
✅ Focus tracking works normally
✅ No stuck mouse clicks
✅ All touchpad gestures work
✅ BTN_0 events successfully filtered

Patch

The fix adds 3 files totaling 99 lines:

drivers/hid/hid-surface.c (new, 90 lines)
drivers/hid/Kconfig (modified, +8 lines)
drivers/hid/Makefile (modified, +1 line)

Patch file: https://github.com/ciarancoffey/linux-surface/blob/fn-key-btn0-fix/patches/6.16/0016-hid-surface-fn-key.patch

Compatibility

Confirmed working: Surface Laptop 4 AMD
Should work on: Surface Laptop 3, 4, 5, and Surface Pro 9 (which reported similar symptoms in [SP9] FN button stops mouse input in other windows #1719)

Request for Testing

If you're experiencing this issue, please test the patch and report back! I'm especially interested in hearing from:

Surface Laptop 3/5 users
Surface Pro 9 users
Users on other compositors (GNOME Wayland, Sway, Hyprland, etc.)

If testing goes well, I'm happy to submit this as a formal PR. The fix is minimal, well-tested on my hardware, and ready for merging.

Technical Details

Key insight: BTN_0 is NOT in the HID descriptor - it's generated dynamically at runtime from HID reports. This is why the fix required using the event callback rather than input_mapping.

Why it affects KWin Wayland specifically: X11 and GNOME Wayland handle stuck button events more gracefully. KWin Wayland's focus tracking is more sensitive to input flooding, though this could be improved on the KWin side as well (separate issue).

Add patch to filter BTN_0 (FN key) events on Surface devices

@RichardODonoghue and @leinaht are you both using KDE on wayland? This seems to be the only combination that triggers this bug for me.

For me this also happens under sway. See https://bbs.archlinux.org/viewtopic.php?pid=2277156

HID: Add hid-surface driver to filter BTN_0 (FN key)

SURFACE: HID: Add hid-surface driver to filter BTN_0 (FN key)

HID: Add hid-surface driver to filter BTN_0 (FN key)

SURFACE: HID: Add hid-surface driver to filter BTN_0 (FN key)

HID: Add hid-surface driver to filter BTN_0 (FN key)

Navigation Menu

Repository navigation

SL4A FN keys not working #1851

Root Cause

Solution

Testing Results

Patch

Compatibility

Request for Testing

Technical Details

49 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

SL4A FN keys not working #1851

Description

Activity

leinaht commented on Sep 9, 2025

ciarancoffey commented on Oct 9, 2025

ciarancoffey commented on Oct 9, 2025

ciarancoffey commented on Oct 10, 2025

Root Cause

Solution

Testing Results

Patch

Compatibility

Request for Testing

Technical Details

Tom-Finke commented on Dec 10, 2025

49 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions