my SIL purchased a Framework 16 DYI a few weeks ago. As she is not too knowledgeable with hardware I helped her put it together and install Windows 11 Pro on it.
After setting up Windows we noticed that the Touchpad and Keyboard+Numpad stopped working from time to time or “hang” on the click/key pressed. After a few seconds they started working normally again. Also the backlight extinguished at the same time.
This sometimes happens every few seconds, sometimes there is half an hour without disruption.
I then took the Framework 16 home with me to debug this further.
I noticed that all devices are attached via USB so I looked further into that.
Turns out that the Numpad & Keyboard Module show USB disconnect/reconnect whenever they stall. Look at the screenshot, green are all USB components that reconnected a short while ago.
This is most likely the cable between mid plate and the main board being loose or damaged.
Or one of the keyboard/spacers/touch pad not making a good connection to the pins.
Try removing the keyboard and touchpad, check the cable, and that there is no dust or anything near the pin contacts where the touchpad or keyboard connect.
Have similar issues with my ‘Laptop 16 Keyboard Module - ANSI’.
While working on a text keyboard randomly disconnects for 2-3 seconds (backlight also stops working).
Checking the dmesg logs I can clearly see that the USB device just disconnects only to be found 1-2 seconds later.
Just over the last 2 hours I had 38 (!) disconnects.
I am not smashing my keys too hard, nothing was ever spilled on it.
And of course I’ve checked the connection, mid-plate cable several times and reseated the keyboard dozens of times over the last few days already.
It’s frustrating.
Every disconnect produces these lines in dmesg:
Apr 22 02:57:47 hostname kernel: usb 1-4.3: new full-speed USB device number 48 using xhci_hcd
Apr 22 02:57:47 hostname kernel: usb 1-4.3: unable to get BOS descriptor set
Apr 22 02:57:47 hostname kernel: usb 1-4.3: New USB device found, idVendor=32ac, idProduct=0012, bcdDevice= 0.29
Apr 22 02:57:48 hostname kernel: usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 22 02:57:48 hostname kernel: usb 1-4.3: Product: Laptop 16 Keyboard Module - ANSI
Apr 22 02:57:48 hostname kernel: usb 1-4.3: Manufacturer: Framework
Apr 22 02:57:48 hostname kernel: usb 1-4.3: SerialNumber: FRAKDKEN0100000000
Apr 22 02:57:48 hostname kernel: input: Framework Laptop 16 Keyboard Module - ANSI as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/1-4.3:1.0/0003:32AC:0012.1E2B/input/input9626
Apr 22 02:57:48 hostname kernel: hid-generic 0003:32AC:0012.1E2B: input,hidraw0: USB HID v1.11 Keyboard [Framework Laptop 16 Keyboard Module - ANSI] on usb-0000:c1:00.3-4.3/input0
Apr 22 02:57:48 hostname kernel: hid-generic 0003:32AC:0012.1E2C: hiddev0,hidraw1: USB HID v1.11 Device [Framework Laptop 16 Keyboard Module - ANSI] on usb-0000:c1:00.3-4.3/input1
Apr 22 02:57:48 hostname kernel: input: Framework Laptop 16 Keyboard Module - ANSI System Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/1-4.3:1.2/0003:32AC:0012.1E2D/input/input9627
Apr 22 02:57:48 hostname kernel: input: Framework Laptop 16 Keyboard Module - ANSI Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/1-4.3:1.2/0003:32AC:0012.1E2D/input/input9628
Apr 22 02:57:48 hostname kernel: input: Framework Laptop 16 Keyboard Module - ANSI Wireless Radio Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/1-4.3:1.2/0003:32AC:0012.1E2D/input/input9629
Apr 22 02:57:48 hostname kernel: input: Framework Laptop 16 Keyboard Module - ANSI Keyboard as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/1-4.3:1.2/0003:32AC:0012.1E2D/input/input9630
Apr 22 02:57:48 hostname kernel: hid-generic 0003:32AC:0012.1E2D: input,hidraw2: USB HID v1.11 Keyboard [Framework Laptop 16 Keyboard Module - ANSI] on usb-0000:c1:00.3-4.3/input2
Apr 22 02:57:48 hostname kernel: hid-generic 0003:32AC:0012.1E2E: hiddev1,hidraw3: USB HID v1.11 Device [Framework Laptop 16 Keyboard Module - ANSI] on usb-0000:c1:00.3-4.3/input3
...
Apr 22 02:58:04 hostname kernel: usb 1-4.3: USB disconnect, device number 48
Any chance of having found a resolution? This is the most interesting thread I’ve found so far, because I have this on Linux 6.15.4 (albeit Debian 12, ppd 0.12), and was thinking it’s a Linux issue.
Seeing Windows mentioned brings me both hope and despair.
And yeah, haven’t opened the laptop many times, the cable is snug, all appears to make contact.
Tried removing the extension plugs, and rearranging them, but when this might be entirely random, one only develops superstitions when doing stuff like that.
Well in the end we replaced the mainboard. Everything else didn’t work. Replaced all input modules and the midplane before that. Framework was very thorough and had me check everything in detail.
Ok, I opened a support issue with them and linked this thread.
After that I noticed that an external keyboard works surprisingly well, like I’m sure I kept typing through some internal disconnects, though sometimes the laptop wouldn’t realize I plugged something in. But when it works it might actually work.
Hopefully this can keep me going for a while, because that component-switching sounds like a long and arduous process.
OTOH I heard earlier today it’s known that FW16s have done this in the past, so maybe they’ll be lenient and just send me what I need after a quick check.
I’m currently going through the same process with Framework Support.
It’s a bit annoying to go through multiple loops of testing different combinations, images, Linux distros and configs. The current thread is already 43 emails long and spanning over 2 months of back and forth.
In any other situation I’d probably give up and demand a full refund.
With Framework I genuinely want to improve the product not just for myself but (hopefully) for the future buyers as well. So I go on with the tests and extensive log gathering.
What I’ve learned so far:
Disconnects occur seemingly at random, no direct relation to any of my actions identified
They happen on every single distro that I’ve tested (Debian, Ubuntu, Fedora - stable & latest builds)
When the laptop itself is hot the disconnect probability is higher
If I actively use the keyboard the disconnect probability is higher
They can happen several times a minute, or they can happen several days apart
Different module arrangements do not resolve the issue.
New mid-plate (replaced via Support) did not resolve the issue
A completely new set of input modules (replaced via Support) did not resolve the issue, but the disconnects happen much less frequently now.
Currently I’m trying to figure out if the situation is different with and without AC power connected.
If there’s no difference the next step is motherboard replacement.
My current theory is that MB overheats under extended load (or with a closed lid) which leads to mid-plate connection issues, which in turn causes the disconnects. Which is strangle as the fans should take care of that.
Keep in mind that I have no deep technical knowledge on the schematics and power lines of FW16, so it’s just a wild guess!
Hope any of that helps.
Additional note: even though the Framework Support team asks for multiple tests and evidence they are really helpful and will go on replace the faulty parts.
After jumping through a few hoops, I was asked to Force On the Force Power for Input Modules setting in BIOS. This made it possible for me to use the laptop, even without an external keyboard, for a long time so far(!) without fail(!!)
Going back and setting it to “Require Modules” caused the issues to come back.
We’re maintaining a holding pattern right now, but as Framework tells me there’s no downside to having this turned on, I dunno what’s next. Surely it’s weird that an advertised function, like the built-in keyboard, doesn’t work without a “toggle this option, don’t think about it too much” setting. And that forcing power on wouldn’t even drain the battery. I dunno.
The thing is, this machine drains battery like crazy EVEN WHEN SUSPENDED, to the point where I sometimes close the lid with music playing just to hear it stop.
I was so caught up in the disappearing keyboard that I don’t know if it’s related, but I’ve had some dmesg traces (with kernels 6.15.4. and 6.15.6) mentioning amdgpu, or more often thunderbolt. I’m only pretty sure I didn’t have those before, but my focus was on the keyboard.
Mad power drain has always been a thing, dmesg traces or not.
(If I wasn’t forced to have two encrypted partitions for work, I might as well just hibernate the machine until something magically gets fixed, but unlocking’s a real annoyance.)
