pop-os / linux

Pop!_OS fork of https://launchpad.net/ubuntu/+source/linux
Other
110 stars 13 forks source link

HP Dev One screen goes black when selecting lower resolutions #286

Closed ahoneybun closed 8 months ago

ahoneybun commented 9 months ago

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)"

thomas-zimmerman commented 9 months ago

This may be related to this bug in 6.5: https://gitlab.freedesktop.org/drm/amd/-/issues/2693

jacobktm commented 9 months ago

I've tried reverting the commits referenced in that bug, and they don't resolve the issue.

thomas-zimmerman commented 9 months ago

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>
jacobktm commented 8 months ago

I tested a kernel with that patch applied and it does resolve this issue

leorochael commented 8 months ago

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.

leviport commented 8 months ago

6.5.6 has just been released.