Display freezes until mouse moves when upgrading above Kernel 6.11.2

gitterrost4 · 2024-10-29 16:19:36

I have a Framework Laptop 16 with no graphics card extension, meaning it uses the on-chip graphics:

$ lspci | grep VGA
c1:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 (rev c2)
$ lscpu |grep Model\ name
Model name:                           AMD Ryzen 7 7840HS w/ Radeon 780M Graphics

Whenever I upgrade to a kernel version higher than 6.11.2 (I tested up to 6.11.5), my screen will not update unless I am moving the mouse. The problem is already visible when in the login screen (I am using X with lightdm as a login manager). I can type in the first character of my password and then it will freeze. I can continue typing and it will register the inputs, but the screen stays frozen until I move my mouse.

The problem persists after logging in. I usually don't use any compositor, but when I start one such as picom, the problem will go away. I don't want to be forced to use a compositor though.

Downgrading the kernel back to 6.11.2 resolves the problem again.

I am not sure what logfiles would be helpful to post here.

seth · 2024-10-29 20:18:55

How close are you to https://bbs.archlinux.org/viewtopic.php?id=300233 wrt WM and colported solution workaround?

gitterrost4 · 2024-10-30 08:06:35

That topic seems to be exactly the same as the one I have (I just wasn't able to find the post again). That's also where I had the picom workaround from.

I don't see anything related to colported on that post though. Can you specify what you mean here?

Otherwise I can close this topic and just attach myself onto the other one.

seth · 2024-10-30 08:23:59

Ah, I stopped reading before

but when I start one such as picom, the problem will go away

That's the workaround colported on that thread, it just doesn't make a whole lot of sense.

The other thread wrote:

This is connected to the kernel. It was introduced in 6.11.3-arch1-1 and is still present in 6.11.4-arch1-1. 6.11.2-arch1-1 works fine, though.

commit e06b1962bc1b7bc1f8829efc3e5fd82021963ce2
Author: Tom Chung
Date:   Wed Jul 3 16:47:57 2024 +0800

    drm/amd/display: Fix VRR cannot enable
    
    [ Upstream commit f91a9af09dea850d83d4b217b8acbafd97b5c61f ]
    
    [Why]
    Sometimes the VRR cannot enable after login to the desktop.
    
    User space may call the DRM_IOCTL_MODE_GETCONNECTOR right after
    the DRM_IOCTL_MODE_RMFB.
    
    After calling DRM_IOCTL_MODE_RMFB to remove all the frame buffer
    and it will cause the driver to disable the crtc and disable the
    link while calling the link_set_dpms_off().
    
    It will cause the dpcd read failed in amdgpu_dm_update_freesync_caps()
    while try to get the DP_MSA_TIMING_PAR_IGNORED capability and think
    the sink side does not support VRR.
    
    [How]
    Use the dpcd_caps.allow_invalid_MSA_timing_param flag instead of
    reading from dpcd directly.
    
    dpcd_caps.allow_invalid_MSA_timing_param flag is updated during HPD.
    It is safe to replace the original method.

◉ grep -C1 picom /usr/share/drirc.d/00-mesa-defaults.conf                    
        </application>
        <application name="picom" executable="picom">
            <option name="adaptive_sync" value="false" />

Try to globally "export adaptive_sync=false" and/ro disable VRR w/ xrandr or xorg.conf.d/some.conf, https://wiki.archlinux.org/title/Variab … figuration

csmnn · 2024-11-01 10:19:47

I tried exporting adaptive_sync=false or setting it to false in an xorg.conf-drop-in-file. This did not change the situation.

This pointed me in the right direction though... while reading the wiki-pages for xorg and amdgpus, I stumbled onto the "tear free"-option. This is set to "auto" by default.

Executing

xrandr --output eDP --set TearFree on

or creating a drop-in-config for Xorg, doing the same thing on boot, makes the display behave normally again.

cat /etc/X11/xorg.conf.d/20-amdgpu.conf
Section "OutputClass"
     Identifier "AMD"
     MatchDriver "amdgpu"
     Driver "amdgpu"
     Option "TearFree" "true"
EndSection

seth · 2024-11-01 12:47:50

\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Edit: this doesn't do much other than the compositor, though

Last edited by seth (2024-11-01 12:48:42)

gitterrost4 · 2024-11-15 21:55:25

This does not solve my issue. When I try executing the xrandr command (switching out "eDP" with "eDP-1" in my setup), I get the following error:

$ xrandr --output eDP-1 --set TearFree on
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  11 (RRQueryOutputProperty)
  Serial number of failed request:  46
  Current serial number in output stream:  46

EDIT: I don't think I am using the amdgpu driver though. At least I don't have xf86-video-amdgpu installed, as the wiki recommends installing mesa instead.

Last edited by gitterrost4 (2024-11-15 21:56:25)

seth · 2024-11-15 22:05:08

Sorry, confused csmnn for the OP
The setting will only work w/ xf86-video-amdgpu

Wrt

I tried exporting adaptive_sync=false or setting it to false in an xorg.conf-drop-in-file. This did not change the situation.

Make sure to export that somewhere in /etc/profile.d/* as you need it to be picked up by the X11 server to do anything meaningful (and "an xorg.conf-drop-in-file" is categorically wrong, this isn't how you set environment variables)

sdmcclain · 2024-12-04 18:11:26

I believe I am facing a similar issue (also on a Framework 16 with an AMD CPU). That said, I am running Sway/Wayland, so I don't think the xorg compositor part is relevant for me? My screen also does periodically refresh on keyboard input (and immediately when I move the cursor).

Any advice on what I should try to resolve this?

sdmcclain · 2024-12-04 18:23:40

I'll need to test this a little further, as I don't think this has fully resolved my issue, but leaving it here in case it helps someone else. Sway recently landed tearing control support, and I have enabled it in my config file, which seems to have alleviated the issue (albeit keyboard input still feels a little heavy/laggy).

# Tearing
output * {
    allow_tearing yes
    max_render_time off
}
for_window [all] allow_tearing yes

seth · 2024-12-05 05:18:29

The 6.12 kernels seem to have introduced a PSR regression for amdgpu, see https://bbs.archlinux.org/viewtopic.php … 4#p2210504

tnarchie · 2024-12-27 20:15:25

I'm using Fedora 41 KDE Spin and I'm having the same issue: display freezing until mouse is moved or some monitoring applet in the task bar updates itself.
This does not happen in Firefox, but e.g. in yakuake terminal, FreeTube or any other video player (vlc, mkv, smplayer etc.). I can only see 1 to 2 frames per second when a video is played or I enter something in the terminal.

The error has probably also existed since kernel 6.11 (I don't remember exactly which minor version), but with kernel 6.10 everything was still fine.
I also use a Framework 16 (like the previous poster) with AMD CPU and dedicated AMD GPU.
I have to fall back to the LTS kernel 6.6 so that I can use my laptop properly. Waking up from standby and hibernation is also affected when I use kernel 6.11 or 6.12.

The worrying thing is that kernel 6.12 is the new long term kernel. With 6.12.6 the problem is still not solved.

Even the kernel parameter “amdgpu.dcdebugmask=0x10”, which is recommended in some threads I have come across, does not bring any change.

I have shared my problem in the this Framework community thread as well, but so far there is also no solution to this: https://community.frame.work/t/fedora-4 … p-16/60005

What can we do? Are the kernel developers aware of this problem? Where can we make our voice heard so that hopefully there will be a fix for the problem soon?

seth · 2024-12-27 21:23:30

Did you test the solution from #5 (pot. along the 6.12 specific “amdgpu.dcdebugmask=0x10” which was not an issue w/ the 6.11 kernels)?

tnarchie · 2024-12-27 22:11:47

As Fedora 41 uses KDE Plasma 6.2.x with Wayland (not X11) I don't know how to implement what is suggested there and if that would even make sense in Wayland.
Using the xrandr command gives me an error similar to the one in post #7. Using the said kernel parameter on its own does unfortunately not solve the issue.

seth · 2024-12-27 22:23:03

No, that's X11 specific.
Properly exporting "adaptive_sync=false" would however work - whether it'll fix your problem is to be seen.
wrt the sway "allow tearing" stuff you could also test "vblank_mode=0" (both would also be picked up from drirc)

tnarchie · 2024-12-27 23:34:59

I have tried the following with kernel 6.12.6:

Added to /etc/environment:
adaptive_sync=false
vblank_mode=0

Added in .bashrc:
export adaptive_sync=false
export vblank_mode=0

And tried the whole thing with the kernel parameter “amdgpu.dcdebugmask=0x10”.

Nothing helped.

seth · 2024-12-28 08:06:48

Where can we make our voice heard so that hopefully there will be a fix for the problem soon?

You should primarily take this to Fedora.
I'd tell you to test the X11 behavior or different wayland compositors, but I guess that's not a thing with your installation/distro/approach?
And in general you're on the wrong board https://bbs.archlinux.org/misc.php?action=rules and you're probably also off-topic, since this thread explicitly concerns uncomposited X11 environments (running picom is a suggested fix) while you're running some pr obably patched version of KDE on wayland what's uncomparable.

Arch Linux

#1 2024-10-29 16:19:36

Display freezes until mouse moves when upgrading above Kernel 6.11.2

#2 2024-10-29 20:18:55

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#3 2024-10-30 08:06:35

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#4 2024-10-30 08:23:59

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#5 2024-11-01 10:19:47

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#6 2024-11-01 12:47:50

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#7 2024-11-15 21:55:25

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#8 2024-11-15 22:05:08

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#9 2024-12-04 18:11:26

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#10 2024-12-04 18:23:40

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#11 2024-12-05 05:18:29

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#12 2024-12-27 20:15:25

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#13 2024-12-27 21:23:30

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#14 2024-12-27 22:11:47

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#15 2024-12-27 22:23:03

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#16 2024-12-27 23:34:59

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

#17 2024-12-28 08:06:48

Re: Display freezes until mouse moves when upgrading above Kernel 6.11.2

Board footer