Function (Fn) Keys Sticking + Fix for Linux

Framework Laptop 13 Linux
6

I did verify with evtest and udevadm info. input2 is indeed the correct input.

After rebooting, I cannot get it to reproduce anymore using the steps you mentioned. It’s possible that since it was already in a “stuck” state at the time that I applied your fix, that it stayed in that state.

We’ll see if it comes back at some point. Until then I can’t really gather any more data.

Fingers crossed that it only didn’t work because I applied after it was already stuck, and that it will stay fixed :slight_smile:

7

@Charles_Daniels I’ve seen oddities where I had to run the commands twice and/or just reboot for the changes to work, but once it does, it stays. Edit: added note about possibly needing to restart.

Hope the reboot worked and that it stays fixed!

8

Thanks for this, I was pulling my hair out trying to figure out why switching workspaces in sway to Xwayland windows was causing my up arrow key to get stuck, though I’m not super thrilled to have to apply this hack on a brand new machine.

1 Like
9

Jumping in here, we can reproduce this, and will work on a fix for 3.07 bios.

7 Likes
10

Wonderful, thank you!

1 Like
11

I’m assuming that this won’t actually appear in 3.07 at this point, so will hopefully appear in some later version, correct? (I think “BETA” is just the status, and the 3.07 version is what it is.)

2 Likes
12

Thank you very much for providing this fix. I use HOME and END a lot while typing and I thought I was going crazy when my cursor would intermittently jump to the end or beginning of a line.

2 Likes
13

I love you. No joke.
For some reason I was not able to find this post easily, so it took me hours of debugging and searching… almost gave up on Linux for this laptop. And you did it! Thank you so much!

2 Likes
14

Haha thanks for the kind words! I sure had those same feelings @Ygor_Dreyer while I was going through this, so I’m glad I could help y’all!

Maybe this should be pinned @moderators so that others can more easily find this, until fixed in an upcoming BIOS version?

1 Like
16

Just to clarify for readers catching up on the thread, looks like the fix for this didn’t make it into the 3.07 bios beta release (as of writing this) since I can still repro so the solution in this thread is still necessary.

1 Like
17

I haven’t noticed the particular function stickiness issue, but I have noticed what other people have been saying regarding certain keys (like Fn + F9 (Display Switching Logo), Fn + F10 (Airplane) not being able to be easily accessible or not generating any entries. I’m on FreeBSD 13.1-STABLE and used ‘xev’ to test on X11. (The same happened though when I was using sway / Wayland on FreeBSD as well - but using ‘wev’ instead).

Fn + F9 yields:

KeyPress event, serial 34, synthetic NO, window 0x1e00001,
root 0x593, subw 0x0, time 21470262, (132,427), root:(3260,451),
state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x1e00001,
root 0x593, subw 0x0, time 21470264, (132,427), root:(3260,451),
state 0x40, keycode 33 (keysym 0x70, p), same_screen YES,
XLookupString gives 1 bytes: (70) “p”
XmbLookupString gives 1 bytes: (70) “p”
XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x1e00001,
root 0x593, subw 0x0, time 21470322, (132,427), root:(3260,451),
state 0x40, keycode 33 (keysym 0x70, p), same_screen YES,
XLookupString gives 1 bytes: (70) “p”
XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x1e00001,
root 0x593, subw 0x0, time 21470322, (132,427), root:(3260,451),
state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

Fn + F10 doesn’t generate any output (Although I don’t believe my machine is intercepting that signal - I’m on i3).

Fn + F12 yields this (Seems like this might be incorrect given it references Audio but it’s the wheel key - I’ll need confirmation).

KeyPress event, serial 34, synthetic NO, window 0x1e00001,
root 0x593, subw 0x0, time 21473824, (132,427), root:(3260,451),
state 0x0, keycode 234 (keysym 0x1008ff32, XF86AudioMedia), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x1e00001,
root 0x593, subw 0x0, time 21473882, (132,427), root:(3260,451),
state 0x0, keycode 234 (keysym 0x1008ff32, XF86AudioMedia), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

18

I just bought a HP Probook and I’m trying Ubuntu on it.
For me the issue was solved by using the Fn Lock option on the keyboard.

Not sure if the framework has that option as a workaround.

19

Yes, the Fn Lock option exists, but that’s not what this issue + its fix is about.

20

Yes, the Framework logo function key (F12) maps to XF86AudioMedia. Others have mentioned that on Windows, it opens up the media center or something (can’t test, since I only run Linux on personal machines).

21

Appologies, I explained things poorly.

On the HP the default state of the keyboard is Fn keys & num pad.
When I engaged the Fn Lock it brings the default state back to the F row and standard keys.

22

Nono, I understood you the first time – thanks for the deeper explanation though! This leads me to believe that you may be misunderstanding what the actual issue is :slight_smile:
I’ll explain at the bottom of this post, and my apologies if I’m misunderstanding you.

This (the Fn lock option) exists on the Framework laptop by pressing Fn + Esc (fn lock) to toggle it. Toggling between the two won’t resolve the issue as it exists in both states (Fn lock off or on).

image
image444×577 58 KB

Explanation

It’s in the original post, but to rephrase succinctly, after pressing the Fn + some modifier key in a known order, that key will stick. Stick meaning the key will act as if it’s repeatedly pressed, or held down.
For example, the volume up key gets “stuck” so that the system keeps increasing volume.
This is because the key up signal isn’t being properly sent.

Sometimes the user won’t know one of the keys is stuck, which can cause one of the keys to “randomly” keep being pressed.
For example, in the middle of typing, the left arrow key sticks so the cursor keeps moving to the left. One can see how this is frustrating during normal use.

On Linux, this pertains to all/most keys with Fn modifiers. On Windows, just brightness up/down.

This is all already detailed in the original post with the software/driver fix for Linux, though. The ultimate fix would be in a BIOS update. It was confirmed to arrive, but didn’t make it to 3.07, so hopefully it will in an upcoming release.

While I’m typing this up – it seems that some manufacturers never get around to fixing this in the EC/BIOS or even acknowledging the issue. So, kudos to Framework!!

2 Likes
23

Ah bugger. That sucks.
Yeah sticky keys are a pain.

24

It looks like BIOS v3.09 fixed this (BIOS 3.09 Beta release); I just removed the udev file and reran the two commands to undo the changes. Fingers crossed that it works!

(I’m guessing this was the fix: Merge pull request #485 from FrameworkComputer/hx20.keyboard_key_scan… · FrameworkComputer/EmbeddedController@fa89820 · GitHub)

3 Likes
25

Hm, I just tried editing my original post and it seems that I can’t – mods, any suggestions? Or please feel free to add a disclaimer at the top about BIOS 3.09!

Thanks for the confirmation @Jake_Bailey, I also just got 3.09 installed and am confirming that it seems to have fixed the issue. Will report back if it still remains.

To uninstall the udev rules see here.

To uninstall the custom driver:

  1. modprobe
  2. DKMS

Thanks @Kieran_Levin/Framework team/those that helped get this fixed. Cheers!

3 Likes