From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
simona@ffwll.ch, airlied@gmail.com, pekka.paalanen@collabora.com,
jadahl@gmail.com, contact@emersion.fr,
maarten.lankhorst@linux.intel.com, mripard@kernel.org
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
spice-devel@lists.freedesktop.org,
wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/9] drm: Limit DRM_IOCTL_WAIT_VBLANK to vblank interrupts
Date: Fri, 15 May 2026 18:56:45 +0200 [thread overview]
Message-ID: <cb461424-e4c1-4d2c-934b-ffd7374e2a56@mailbox.org> (raw)
In-Reply-To: <b5d03921-1e6f-4c4f-900e-fc9e28222176@mailbox.org>
[ 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
prev parent reply other threads:[~2026-05-15 16:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 11:55 [PATCH 0/9] drm: Limit DRM_IOCTL_WAIT_VBLANK to vblank interrupts Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 1/9] drm/vblank: Add drmm_vblank_init() to indicate managed cleanup Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 2/9] drm/vblank: Add DRM_VBLANK_FLAG_SIMULATED Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 3/9] drm/amdgpu: vkms: Set DRM_VBLANK_FLAG_SIMULATED Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 4/9] drm/bochs: " Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 5/9] drm/cirrus: " Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 6/9] drm/hypervdrm: " Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 7/9] drm/qxl: " Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 8/9] drm/virtgpu: " Thomas Zimmermann
2026-05-15 11:55 ` [PATCH 9/9] drm/vkms: " Thomas Zimmermann
2026-05-15 15:12 ` [PATCH 0/9] drm: Limit DRM_IOCTL_WAIT_VBLANK to vblank interrupts Michel Dänzer
2026-05-15 16:56 ` Michel Dänzer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb461424-e4c1-4d2c-934b-ffd7374e2a56@mailbox.org \
--to=michel.daenzer@mailbox.org \
--cc=airlied@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=contact@emersion.fr \
--cc=dri-devel@lists.freedesktop.org \
--cc=jadahl@gmail.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=pekka.paalanen@collabora.com \
--cc=simona@ffwll.ch \
--cc=spice-devel@lists.freedesktop.org \
--cc=tzimmermann@suse.de \
--cc=virtualization@lists.linux.dev \
--cc=wayland-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox