[ Adding the wayland-devel list for awareness ]

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?

In the case of the asahi & nvidia drivers, the problem with exposing this 
functionality to user space is that if the timestamps aren't accurate, it can 
result in missing display refresh cycles, which are dictated by hardware. 
That's why it makes sense to reject it there.

When there's no strict refresh cycle, that issue doesn't apply though.


Any changes made to the WAIT_VBLANK ioctl should also be made to the 
CRTC_GET_SEQUENCE / CRTC_QUEUE_SEQUENCE ioctls, which are slightly different 
UAPI for the same functionality.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Reply via email to