On 5/27/26 15:07, Thomas Zimmermann wrote: > Am 15.05.26 um 18:56 schrieb Michel Dänzer: >> On 5/15/26 17:12, Michel Dänzer wrote: >>> On 5/15/26 13:55, Thomas Zimmermann wrote: >>>> DRM's WAIT_VBLANK ioctl synchronizes user-space clients to display >>>> refresh. This is meaningless with vblank timers, which run unrelated >>>> to the hardware's vblank. >>>> >>>> Disable the ioctl for simulated vblanks. Set DRM_VBLANK_FLAG_SIMULATED >>>> for CRTCs with simulated vblank events in all such drivers. The vblank >>>> timers of these devices still rate-limit the number of page-flip events >>>> to match the display refresh. >>>> >>>> According to maintainers, user-space compositors do not require the ioctl >>>> for rate-limitting display output. Weston and Kwin rely on page-flip >>>> events. Mutter uses and internal timer to limit the number of display >>>> updates per second. >>> Actually mutter fundamentally relies on atomic commit completion events for >>> that, same as Weston & KWin. Mutter uses the WAIT_VBLANK ioctl only for >>> minimizing input → output latency (which can hide issues when completion of >>> atomic commits isn't properly throttled). >>> >>> >>> (Just a side not on the cover letter, no objections to the patches >>> themselves) >> After more discussion on IRC, I have some concerns. >> >> >> The big one first: For drivers with no strict refresh cycle (i.e. an atomic >> commit can take effect more or less anytime after at least one "refresh >> cycle" has passed since the last one), does this change really make sense / >> what's the actual benefit? > > I don't have a strong opinion on that matter. I just think we should clarify > the meaning of these ioctls. > > Timing page flip is currently not supported on any driver without hardware > vblank IRQ or a vblank timer. The situation might vary among compositors, but > there have been plenty of reports of animation and frame rates either being > too high or too low.
As discussed on IRC, that's due to insufficient throttling of atomic commits in the kernel, not directly related to the functionality in this series. > So I think we should rollout vblank timers for all drivers without hardware > vblank IRQ. I'm not arguing against that. It doesn't necessarily invalidate my concern though. > Right now, vblank timers act like a vblank IRQ in these ioctls. That's a > convenient position for user space. > > But we don't really sync anything with hardware here, so the alternate > proposal is to not support them. This also appears to be the original > intention of these ioctls. Speaking as the creator of the DRM_IOCTL_WAIT_VBLANK ioctl, I'm afraid it's not that simple. While it's true that the ioctl was originally only available if backed by corresponding HW & driver support, that's mostly because vblank timers and the scenarios which motivated them weren't really a thing until much later though, not an explicit intention at the time. I created it to give user space information about the display refresh cycle timing, and to allow it to synchronize to that. This seems like it could be useful even with vblank timers. At least if this ioctl and atomic commits are properly integrated, similar to how they are with a proper HW display refresh cycle, which I'm not sure is currently the case though. > Vblank timers would just limit the internal page-flip rate, but nothing else. > That's the more defensive approach. If those two things aren't properly integrated though, then this might indeed be less bad than the status quo. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
