I have today received a Framework Laptop 13 (12th Gen Intel Core), and proceeded to install Debian GNU+Linux. I am using the current Debian “bookworm”.
The graphical display (used for GDM and its X sessions) flickers and tears terribly; it seems to be showing several partial copies of the screen, rotating every second or so.
This might be a “frame buffer” problem? I have checked whether kernel, firmeware, or OS package updates can fix this. With the latest available in Debian “bookworm”, the problem continues.
This makes the computer effectively unusable for the intended customer.
How can I diagnose this and restore the screen to steady correct display?
1 Like
For reference, some of the relevant package versions:
- linux-image-amd64: 6.1.15-1
- firmware-misc-nonfree: 20210818-1
- xwayland: 2:22.1.18-1
1 Like
Hello!
Could you please:
1.) Attach a photo or video of the issue, if possible
2.) Check if it helps to disable Panel Self Refresh (PSR)? See [Warning] Ubuntu 21.10 Wayland issues - #8 by Rob_H
I have found the post My screen flickers sometimes where the poster describes adding a boot option in the Grub settings.
This did not work for me; Grub shows that the option is present on the kernel command line, but the screen flicker continues unaffected.
That link doesn’t work …
Anyway, have you tried checking the display connector cable?
Does this issuse also happen on graphical live-ISOs?
Do you have a picture/video of it?
The screen that is flickering is the built-in display on the Framework notebook computer.
Here are some photos of the flicker at various times. Moving the mouse (causing the display to change) appears to exacerbate the problem; “parts” pop in and out of visibility.
That looks like driver issues.
Can you boot up the graphical Ubuntu Live-ISO and see if that works?
Where do I find that exact “Ubuntu Live-ISO” file?
When I installed testing on my 12th Gen I had to manually install a couple of firmware files missing from the install medium for whatever reason
Edit: I imagine there’s an update-initramfs command or similar you can run to first verify if you are missing that firmware
Thank you @juancnuno, I found there some of the missing firmware files that the ‘update-initramfs’ process was complaining about. For future reference, the Debian wiki describes this for Framework 12th gen displays.
Unfortunately, despite the absence now of error messages for missing firmware, the display problem continues as before: parts of the display flicking in and out of visibility in a “torn” way as the display updates.
@Anachron when I boot the Ubuntu 22.0.4.2 Live on a USB stick on this machine, yes the display works correctly. Updating the display does not cause any fracturing / tearing.
The problem continues when booted in Debian as before, even with the firmware for i915 added. I need to get this working with Debian “bookworm”.
How can I diagnose this further? What log output, etc., can I show that will help find and fix the problem?
You could check the output of dmesg and journalctl.
Debian Bookworm came out in Late 2021, but the 12th gen 1240P came out in Q1/2022.
I fear that is not going to work as it’s just too old to have support for such a new hardware.
I suggest to install something else (more recent) and use a Virtual Machine for Debian Bookworm.
Howdy @Anachron,
You might be thinking of a different distribution, not “bookworm”. Debian “bookworm” is (as of 2023-04) still in development and has not yet been released:
As the “testing” distribution, it gets updates multiple times per day.
This is why I’ve chosen to install Debian “bookworm”, because it is the current “testing” distribution of Debian GNU+Linux and so has the latest kernel and drivers.
I have the complete output of dmesg and journalctl now, from recent booting of both the installed Debian “bookworm” operating system, and the Ubuntu 22 live USB stick.
The files are large of course, with a great many log messages.
How should I go about using these to find what’s wrong with the display under Debian? What specifically is going to show up in these log messages, that will point to the problem?
The bad news: With all the diagnostic information, I never found out what the problem was.
The good news: In the time since I first downloaded an installer image, a new installer image for Debian “bookworm” has been released (version “alpha2”). When I re-install using that, it sets up the operating system with the display and all hardware working correctly.
Thank you to everyone who helped me with this.
1 Like
Thank you @Ben_Finney for updating your Thread, that despite debian bookworm’s issue, it’s alpha 2 somehow worked for now, will mark this as Solved for now.
1 Like
This problem reappeared after some other changes. So, an updated Debian and an updated Linux were not the (sole) resolution of this problem.
What is working for me now was a work-around suggested in a thread elsewhere at Framework community, and in a couple of Freedesktop bug reports 2352 2354.
The work-around is:
Add to the Linux command line, the option amdgpu.sg_display=0.
On Debian GNU+Linux, this is easiest to do by editing the ‘/etc/default/grub’ configuration variable GRUB_CMDLINE_LINUX_DEFAULT, to include that option.
(The option is apparently referring to AMD’s “Scatter/Gather” processor feature, which they’ve recently turned on by default?)
With that option disabled, now the display can turn off (e.g. when the computer is suspended), and when it comes back on, the display is the same as when it turned off, no garbage artifacts like before.
I don’t know what the actual bug is. Nor do I know what I’m losing by using this work-around (maybe GPU performance?). I hope this bug is fixed, but don’t know when it’ll be fixed.
1 Like
