FN key/EC problems

Framework Laptop 13
, ,
1

I used to be a fan of Framework’s products, and considered myself a brand ambassador, but I now no longer recommend them, as they simply don’t care to fix problems like this. Just like the other OEM’s, once you buy it; Good luck!

After being up for a while, I keep experiencing a problem where my FN key dies. It has no function if pressed, and all my FN keys act as though the FN lock is on, meaning they press F1-F12 rather than the normal functions. The only fix for this is an EC reset, which of course means I have to reboot the whole thing. This is in conjunction with my USB port “short circuit” that occasionally disables half my USB ports, and also cannot be fixed without a full EC reset. This problem seems to be triggered most often by suspend/resume from closing the lid and re-opening.

If anyone from framework sees this, at least please give us a way to reset the EC without rebooting the whole machine (if possible).

OS: Ubuntu 22.04 LTS

1 Like
2

For your Fn key: This was fixed quite some time ago. With a version of Ubuntu that old, you may not have a kernel version that has the fix.

What kernel version (and Ubuntu patch level) are you running?

FWIW: I am the person to blame for it breaking, not Framework. It also cannot be truly fixed without a hardware revision (which they have done; all platforms shipped after and including the AMD 7040 series have the fix), only worked around in software. Software which Framework does not control, but did review the workaround patch for. I feel they’ve discharged their duties as required of them for post-product support.

Would you like to level the same complaints you did above but against the Linux kernel development community, or against me for breaking it for you? :slight_smile:

3 Likes
3

Wow, I assumed this was the EC not the kernel! Apologies for the bad assumption.

My Kernel: Linux version 6.8.0-88-generic (buildd@lcy02-amd64-004) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #89-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct 11 01:02:46 UTC 2025

1 Like
4

So I’m confused by your response; is this hardware or software? Or a hardware problem with a software work around that doesn’t always work? Is there a solution?

5

Alright, now that I’m in front of a computer.

A little backstory.

The first three iterations of the Framework Laptop use a Microchip MEC-series embedded controller. The MEC has a communication protocol that requires a low- or no-contention bus. To talk to the EC, ACPI (which contains code to check the battery charge levels, report that the OS has finished waking from sleep, etc.) and the kernel need to:

  1. write an address to an EC register
  2. read or write data from a different EC register
  3. repeat [2] until complete

Since ACPI and the kernel could both be competing for access to the EC, they can corrupt eachother’s in-flight requests (by the kernel writing to the address register while ACPI is reading the data registers, etc.)

I originally lit up support for Linux to talk to the Framework EC (back in kernel 5.18 or so.) I was unaware of this bus contention issue when I did.

It happens a lot during wake from sleep, where ACPI is reporting to the EC that it’s back in the OS. The kernel is trying to read EC console logs or something at the same time. The EC never learns that the OS is running, and never re-enables the high-level keyboard functions[1].

Anyway. There’s an ACPI mutex that the kernel can grab to say “hey stop talking to the EC for a sec”.

One of the community members here submitted this patch series to make it do that. Now they can coexist.

I believe this only rolled out with kernel 6.11 and above. I am not aware that it has been backported to any of the LTS/stable branches, nor am I sure that Ubuntu has or has not backported it themselves.

This isn’t an issue on AMD 7040-series boards and newer because they moved to a Nuvoton EC with a different (and simpler) communication protocol that is not subject to races like this.

Anyway: if you need a quick fix and don’t need to talk to the EC from userspace, put the cros_ec_lpcs module on your module disallow list. You can also try a more targeted fix, disallowing cros_ec_debugfs (which accounts for a great many of the early-wake reads originated by the kernel.)

  1. Which are disabled so that F1-F12 work like normal no matter the Fn Lock state during pre-boot. ↩︎

4 Likes
6

Ahh, ok. Makes sense! Thanks for the information, much appreciated!