Hi Johan,
I'm seeing the same issue as György on the x1e80100 CRD and Lenovo ThinkPad T14s. Without this patch, the internal display fails to resume properly (switching VT brings it back) and the following errors are logged:
[dpu error]connector not connected 3 [drm:drm_mode_config_helper_resume [drm_kms_helper]] *ERROR* Failed to resume (-22)
I see the same symptoms with Xorg as well as sway.
The issue of "internal display fails to resume properly (switching VT brings it back)" also affects sc7180 platform during some resumes. Do you see the issue consistently during every resume?
Can we please get this fixed and backported as soon as possible?
Even if there are further issues with some "Night Light" functionality on one machine, keeping this bug as workaround does not seem warranted given that it breaks basic functionality for users.
I suspect this is not about "further issues with some 'Night Light' functionality on one machine", but rather a more fundamental issue or race condition in the qcom DRM devices stack, that is exposed when applying this patch. With this patch applied DRM device state is lost after resume and setting the state is no longer possible. Lots of kernel errors are printed if attempting to set DRM state such as the Color Transform Matrix, when running a kernel with this patch applied. Back in July 2024 I tested this patch on top of 6.9.8 and next-20240709, observing below snippet being logged tens of times:
[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]failed to get dspp on lm 0 [drm:_dpu_rm_make_reservation] [dpu error]unable to find appropriate mixers [drm:dpu_rm_reserve] [dpu error]failed to reserve hw resources: -119
Full logs are attached at https://gitlab.freedesktop.org/drm/msm/-/issues/58.
The x1e80100 is the only platform I have access to with a writeback connector, but this regression potentially affects a whole host of older platforms as well.
Have you attempted setting CTM or other DRM state when running with this patch?
Best regards Leonard