Closed ahoneybun closed 8 months ago
This may be related to this bug in 6.5: https://gitlab.freedesktop.org/drm/amd/-/issues/2693
I've tried reverting the commits referenced in that bug, and they don't resolve the issue.
I wonder if this patch that hit 6.5.6 is the fix:
commit 79aec38ba852ef1219e6e7c65052a14f343b7da7
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date: Wed Sep 13 14:48:08 2023 -0400
drm/amd/display: fix the ability to use lower resolution modes on eDP
commit 2de19022c5d7ff519dd5b9690f7713267bd1abfe upstream.
On eDP we can receive invalid modes from dm_update_crtc_state() for
entirely new streams for which drm_mode_set_crtcinfo() shouldn't be
called on. So, instead of calling drm_mode_set_crtcinfo() from within
create_stream_for_sink() we can instead call it from
amdgpu_dm_connector_mode_valid(). Since, we are guaranteed to only call
drm_mode_set_crtcinfo() for valid modes from that function (invalid
modes are rejected by that callback) and that is the only user
of create_validate_stream_for_sink() that we need to call
drm_mode_set_crtcinfo() for (as before commit cb841d27b876
("drm/amd/display: Always pass connector_state to stream validation"),
that is the only place where create_validate_stream_for_sink()'s
dm_state was NULL).
Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2693
Fixes: cb841d27b876 ("drm/amd/display: Always pass connector_state to stream validation")
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I tested a kernel with that patch applied and it does resolve this issue
The patch mentioned by @thomas-zimmerman, has been applied in kernel versions 6.5.6 and and above, so a kernel upgrade should solve this issue.
6.5.6 has just been released.
This seems to be similar to issue #269 but a little different, it's similar because switching to Wayland causes the issue to not happen anymore.
We have recreated this on two lab units and happens with HP's team unit and a customer. HP's report:
"I just installed Linux kernel 6.5.4 on my HP Dev One running Pop!_OS, but unfortunately, when I tried to change the display resolution after using that kernel, my system completely froze and the screen displayed nothing.
So I reverted back to Linux kernel 6.4.6, where I was having other issues trying to change the display resolution, but at least under 6.4.6 the system does not freeze and I am able to use my HP Dev One.
I just upgraded to 6.5.4 and it goes black when choosing 1680 x 1050 (16:10) then after 30 sec orso it comes back and its reverted to 1920 x 1080 (16:9). A lower resolution is staying black and is black after a reboot. Oldkern booted up to the resolution I chose 1280 x 720 (16:9)"