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: >>>> Why couldn't a full modeset? >>> >>> As far as I see it the only reasons why we should be timing out is >>> either an interrupt went missing (perhaps due to a race condition in >>> driver code) or hung hardware. In either case, the interrupt associated >>> with the page flip for the current commit is long gone. >> >> That's a matter of bookkeeping, the interrupt isn't required to keep track >> of the commit and complete it. > > Oh, if you're talking about sending out a "fake" > drm_crtc_send_vblank_event(), I had considered that. Though, > drivers that have hardware vblank counters take ownership of the > relevant `struct drm_pending_vblank_event` [1] pretty early on. > So, there wouldn't be a way to ensure that they send that out > and that would mean we never get a chance to force a full modeset.
"never get a chance" why? The driver can do a full modeset and then send out the event(s) with the current vblank sequence number(s) and timestamp(s) at that time. >>>> 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). (Just one more reason why kicking the full modeset can down to user space is questionable) -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
