[RESPONDED] Framework 13th gen DIY Ubuntu - Screen super laggy (1FPS) on occasion

Hi @Timothy_Robinson, welcome to the community!

  • You indicated it’s connected to an external display. How is it connected? Expansion card or dock or other type of adapter? If dock or specific adapter not of Framework design, make/model?

  • With the display attached (wayland or xorg, doesn’t matter):

  • Output of running this in the terminal, please copy and paste the output here. xrandr

  • What is the output of uname -r as well?

This happened again today. It happened after starting the laptop after it ran out of power so it may only happen when it’s low on battery? (This isn’t confirmed)

The external display is connected through a Display Port 1.4 cable connected to a Lenovo Thinkpad dock which is connected to the framework via a USB-C cable.

xrandr output:

Screen 0: minimum 320 x 200, current 4176 x 1504, maximum 16384 x 16384
eDP-1 connected primary 2256x1504+0+0 (normal left inverted right x axis y axis) 285mm x 190mm
   2256x1504     60.00*+
   1920x1440     60.00  
   1856x1392     60.00  
   1792x1344     60.00  
   2048x1152     60.00  
   1920x1200     60.00  
   1920x1080     60.00  
   1600x1200     60.00  
   1680x1050     60.00  
   1400x1050     60.00  
   1600x900      60.00  
   1280x1024     60.00  
   1400x900      60.00  
   1280x960      60.00  
   1440x810      60.00  
   1368x768      60.00  
   1280x800      60.00  
   1280x720      60.00  
   1024x768      60.00  
   960x720       60.00  
   928x696       60.00  
   896x672       60.00  
   1024x576      60.00  
   960x600       60.00  
   960x540       60.00  
   800x600       60.00  
   840x525       60.00  
   864x486       60.00  
   700x525       60.00  
   800x450       60.00  
   640x512       60.00  
   700x450       60.00  
   640x480       60.00  
   720x405       60.00  
   684x384       60.00  
   640x360       60.00  
   512x384       60.00  
   512x288       60.00  
   480x270       60.00  
   400x300       60.00  
   432x243       60.00  
   320x240       60.00  
   360x202       59.99  
   320x180       59.99  
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-3-1 disconnected (normal left inverted right x axis y axis)
DP-3-2 disconnected (normal left inverted right x axis y axis)
DP-3-3 connected 1920x1080+2256+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+ 144.00   120.00   119.88   119.98    99.93    74.97    50.00    59.94  
   1280x1024     75.02    60.02  
   1280x720      60.00    50.00    59.94  
   1024x768     119.93    99.99    75.03    70.07    60.00  
   832x624       74.55  
   800x600      119.93    99.86    72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480      119.80    99.83    75.00    72.81    66.67    60.00    59.94  
   720x400       70.08

Uname -r:


The dock is likely where this is falling down. Checking dmesg and journalctl would tell us for sure. Also, we recommend using the kernel provided in our guide.

Not sure you read my original post completely. The external display is working perfectly. It’s the laptop screen that’s having issues. It has been having this issue more frequently lately, and it happens when not plugged into the dock too.

I installed that custom kernel and it’s working better again, but as it only happens on occasion it’s hard to tell if it’s fixed or not.

1 Like

Understood, appreciate the clarification.

If it happens again, open a terminal and check dmesg for any insights as to what might be happening.

Hi. Would like to remark that I’ve had this issue as well. Here’s my info:

Model: Framework Laptop 13 AMD Ryzen 7040 Series
Operating System: Fedora 39 Workstation Edition
Kernel: Linux 6.5.2-301.fc39.x86_64
Frequency: twice, 10 days apart, in the 16 days I’ve had it
Duration: until shutdown
Description: Debilitatingly bad refresh rate and delay. Starts happening in middle of use with no apparent triggering event.

What does’t fix it:

  • Closing all applications
  • Changing refresh rate or scale in display settings
  • Logging out

What does fix it:

  • Restarting
  • Powering off, and then back on


  • display doesn’t update while continually moving the cursor with the touchpad
  • display is less than 4fps when not moving cursor

I have only used my laptop without an external monitor so I can’t confirm whether it would be affected by the issue in my case. I didn’t have the foresight to run xrandr while it was happening, but here are the current results if it’s any help.

Screen 0: minimum 16 x 16, current 1503 x 1002, maximum 32767 x 32767
eDP-1 connected primary 1503x1002+0+0 (normal left inverted right x axis y axis) 280mm x 190mm
   1503x1002     59.85*+
   1280x960      59.94  
   1152x864      59.96  
   1024x768      59.92  
   800x600       59.86  
   640x480       59.38  
   320x240       59.52  
   1440x900      59.89  
   1280x800      59.81  
   1152x720      59.75  
   960x600       59.63  
   928x580       59.88  
   800x500       59.50  
   768x480       59.90  
   720x480       59.71  
   640x400       59.95  
   320x200       58.96  
   1368x768      59.88  
   1280x720      59.86  
   1024x576      59.90  
   864x486       59.92  
   720x400       59.55  
   640x350       59.77

I don’t know that it’s related, but just in case it is I’ll mention that sometimes when opening the laptop, portions of the screen flash white very quickly, however the cursor shows on top of the flashing area when moved over it. Which area is affected depends on the time, but it’s always a continuous wrapping band like the following (O being the white flashing area). My hunch is that it has something to do with pinched cables, but I don’t have a good understanding of how that would work, or why it wouldn’t affect the cursor.

+--------+    +--------+
|        |    |     OOO|
|  OOOOOO| or |OOOOOOOO|    
|OOOOOOOO|    |OOO     |
+--------+    +--------+

Repeated closing/opening with some gentle percussive maintenance fixes this after a few attempts.

Let’s get you up to current, you’re pretty behind. Should be at least 6.5.10-300.fc39.x86_64, but current is 6.5.11-300.fc39.x86_64.

Also, can I get the output from this:

sudo dnf install lshw dmidecode -y && sudo dmidecode | grep -A3 'Vendor:\|Product:' && sudo lshw -C cpu | grep -A3 'product:\|vendor:'`

I’ve seen 6.5.10 Workstation and 6.5.11 Workstation as options when booting up, and selected them a few times to try to stay current, but on next boot it always defaulted back to selecting 6.5.2 Workstation Prerelease. My guess is that it has something to do with having installed the Fedora 39 Beta, as that was the recommended choice before the stable release. I haven’t seen a large “Update” button in the Store like on my Fedora 38 machine, so I’m not sure how to get it to default to the stable.

Here’s my output for the command. Looks like the firmware update I had to do earlier worked as it’s on 03.03

	Vendor: INSYDE Corp.
	Version: 03.03
	Release Date: 10/17/2023
	Address: 0xE0000
       product: AMD Ryzen 5 7640U w/ Radeon 760M Graphics
       vendor: Advanced Micro Devices [AMD]
       physical id: 4
       bus info: cpu@0
       version: 25.116.1

This sounds like [RESPONDED] Error waiting for DMUB idle: status=3.

If you can manage to get to a root shell, do you see those “DMUB” messages when you run dmesg?

@Max_Pearce_Basman once we have you sorted on the right kernel, please see above. This will be the next step if this is still happening. as Sharp points out.

Let’s get you sorted on the Beta:

When trying to run sudo dnf system-upgrade download --releasever=39 I’m getting Error: Need a --releasever greater than the current system version.
Presumably because I’m technically already on 39, just the Beta.

I already see and can boot into the normal Fedora 39 using the 6.5.11 kernel, as it appears as an option in the boot menu. My problem is that it isn’t the default choice.

Here’s /etc/default/grub if it helps

GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"

GRUB_DEFAULT=saved might not be coming into effect because there isn’t a GRUB_SAVEDEFAULT=true entry which I saw in some tutorials online (maybe it defaults to false?)
I’m hesitant to touch grub without knowing more though. The simple sudo update-grub isn’t for Fedora and I’d rather not mess up my system by using a command I don’t understand.

Always worth backing up grub.

sudo cp /etc/default/grub /etc/default/grub.bak

If it all goes sideways, we can always have you chroot into the install and revert it back.

Also a good time to remind anyone reading this, backups are important.

@Max_Pearce_Basman your grub looks correct. And if you’ve been running sudo dnf update ongoing, you should be current (which should have you with 6.5.12-300.fc39.x86_64

  • Leave GRUB as is. :slight_smile:
  • sudo dnf update
  • Reboot

Give this a try.

Good call on the backups.
For context here are my boot options:

Fedora Linux (6.5.12-300.fc39.x86_64) 39 (Workstation Edition)
Fedora Linux (6.5.11-300.fc39.x86_64) 39 (Workstation Edition)
Fedora Linux (6.5.2-301.fc39.x86_64) 39 (Workstation Edition Prerelease)
Fedora Linux (0-rescue-<randomcharacers>) 39 (Workstation Edition Prerelease)

I have been staying up to date, and it still boots to 6.5.2
I’ve selected 6.5.12 manually, and while it works, upon restart or next boot it still defaults back to 6.5.2

Odd, should be booting correctly on a vanilla install. may be worth changing GRUB_DEFAULT=saved to GRUB_DEFAULT=0, then sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Also worth applying this and rebooting:

sudo dnf upgrade --refresh

Thanks! That seemed to do the trick and I’m now on the right version. As for the stuttering screen, I ran sudo dmesg when it came up, which ended up just repeating

[drm:dc_dmub_srv_cmd_run_list [amdgpu]] *ERROR* Error queueing DMUB command: status=2

It did this both before and after resolving the update problem.
My ancillary graphical corruption/flashing issue also still occurs.

Just confirming, you are now seeing this on 6.5.12 with freezing?

As I re-read this, what is attached to your Framework and how is it attached? So I might try to replicate this.

I’ve seen issues with DMUB in the past, namely Debian.

But I have yet to have the stuttering experience you described. So I’d like to replicate the setup for replication on my end and potencially a bug report.

Yes, the two logs I recorded start with

[    0.000000] Linux version 6.5.2-301.fc39.x86_64


[    0.000000] Linux version 6.5.12-300.fc39.x86_64

respectively (the latter being one I recorded after resolving the boot selection).

What do you mean by attached? It didn’t happen to occur in the few times I was using an external monitor, and I just use the touchpad, so the laptop wasn’t attached to anything (except the network in an abstract way I suppose). Edit: The laptop might have been charging at the time if that’s relevant.

I’ll add more context, in case it helps.

Two of the times, it happened when I was on a graphically-intensive website (specifically connecting to virtual table-top software that renders lighting client-side).
One of the other times it happened while I was completing a complex equation in desmos. These don’t have much in common, so I don’t know that it’s anything more than a coincidence.

As mentioned I have two dmesg logs I saved. I tried putting them here but it’s beyond the character limit. If there’s a way to attach it let me know; it doesn’t seem to be a supported file type. I’ll also try to screen record if it happens again, as it’s hard to convey the “texture” of lag with just words.

Had it again, and took a screen recording as well as filming the screen. Let me know if/how to share them with you.

So with an attached display and without, appreciate the clarification.

I have not had success with trying to replicate this - attached display or merely internal display.

  • Try booting from a current ISO of Fedora 39 (latest release copy) on a USB key. It will be an older kernel, but, it will also be a clean environment. Try the problem website there.

  • If you are able to replicate it in the live environment as well, still seeing the DMUB messaging error in the logs, please file a bug report.