On 2/18/26 10:22, Michel Dänzer wrote: > On 2/18/26 01:45, Hamza Mahfooz wrote: >> On Mon, Feb 16, 2026 at 10:28:13AM +0100, Michel Dänzer wrote: >>> On 2/14/26 23:16, Hamza Mahfooz wrote: >>>> On Sat, Feb 14, 2026 at 03:02:49PM +0100, Michel Dänzer wrote: >>>> >>>>> In principle it's possible to do (the equivalent of) a modeset with the >>>>> current state for all CRTCs, no need to do it separately per CRTC. >>>> >>>> AFAIK that is what the uevent is already doing (unless I'm mistaken). >>> >>> This is about just doing a full modeset, which isn't something user space >>> can do in response to a wedged event. >> >> I was referring to what compositors are doing in response to >> `drm_kms_helper_hotplug_event()`. Perhaps, the enum constants should be >> renamed, since the forced modeset is actually sent when the current >> reset phase is DRM_KMS_RESET_NONE (the phase is updated before sending >> out the event though). > > Ah, you're talking about the drm_kms_helper_hotplug_event call in > drm_atomic_helper_wait_for_flip_done (I thought "uevent" referred to > drm_dev_wedged_event in patch 2). > > I don't know about other compositors, but I don't think mutter will do a > modeset in response to a hotplug event if no KMS state changed (because some > monitors can generate spurious hotplug events).
FWIW, if it really turns out impossible for the kernel to do a modeset itself (which I remain unconvinced of), one way to require a modeset from user space is to set the "link-status" connector property to "Bad". -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
