From: Julian Orth <ju.orth@gmail.com>
To: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
linux-doc@vger.kernel.org, wayland-devel@lists.freedesktop.org,
ju.orth@gmail.com
Subject: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
Date: Sat, 16 May 2026 13:06:03 +0200 [thread overview]
Message-ID: <20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com> (raw)
This series adds a new device /dev/syncobj that can be used to create
and manipulate DRM syncobjs. Previously, these operations required the
use of a DRM device and the device needed to support the DRIVER_SYNCOBJ
and DRIVER_SYNCOBJ_TIMELINE features.
There are several issues with the existing API:
- Syncobjs are the only explicit sync mechanism available on wayland.
Most compositors do not use GPU waits. Instead, they use the
DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to perform a CPU wait. Being tied to
DRM devices means that compositors cannot consistently offer this
feature even though no device-specific logic is involved.
- llvmpipe currently cannot offer syncobj interop because it does not
have access to a DRM device. This means that applications using
llvmpipe cannot present images before they have finished rendering,
despite llvmpipe using threaded rendering.
- Clients that do not use the Vulkan WSI need to manually probe /dev/dri
for devices that support the syncobj ioctls in order to use the
wayland syncobj protocol.
- Similarly, clients that want to use screen capture have no equivalent
to the WSI and are therefore forced into that path.
- Having to keep a DRM device open has potentially negative interactions
with GPU hotplug.
- Having to translate between syncobj FDs and handles is troublesome in
the compositor usecase since syncobjs come and go frequently and need
to be cleaned up when clients disconnect.
/dev/syncobj solves these issues by providing all syncobj ioctls under a
consistent path that is not tied to any DRM device. It also operates
directly on file descriptors instead of syncobj handles.
The series starts with a number of small refactorings in drm_syncobj.c
to make its functionality available outside of the file and without the
need for drm_file/handle pairs.
The last commit adds the /dev/syncobj module. I've added it as a misc
device but maybe this should instead live somewhere under gpu/drm.
An application using the new interface can be found at [1].
[1]: https://github.com/mahkoh/jay/pull/947
---
Julian Orth (12):
drm/syncobj: add drm_syncobj_from_fd
drm/syncobj: add drm_syncobj_fence_lookup
drm/syncobj: make drm_syncobj_array_wait_timeout public
drm/syncobj: add drm_syncobj_register_eventfd
drm/syncobj: have transfer functions accept drm_syncobj directly
drm/syncobj: add drm_syncobj_transfer
drm/syncobj: add drm_syncobj_timeline_signal
drm/syncobj: add drm_syncobj_query
drm/syncobj: fix resource leak in drm_syncobj_import_sync_file_fence
drm/syncobj: add drm_syncobj_import_sync_file
drm/syncobj: add drm_syncobj_export_sync_file
misc/syncobj: add new device
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
drivers/gpu/drm/drm_syncobj.c | 374 ++++++++++++++-----
drivers/misc/Kconfig | 10 +
drivers/misc/Makefile | 1 +
drivers/misc/syncobj.c | 404 +++++++++++++++++++++
include/drm/drm_syncobj.h | 21 ++
include/uapi/linux/syncobj.h | 75 ++++
7 files changed, 795 insertions(+), 91 deletions(-)
---
base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6
change-id: 20260516-jorth-syncobj-d4d374c8c61b
Best regards,
--
Julian Orth <ju.orth@gmail.com>
next reply other threads:[~2026-05-16 11:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-16 11:06 Julian Orth [this message]
2026-05-16 11:06 ` [PATCH 01/12] drm/syncobj: add drm_syncobj_from_fd Julian Orth
2026-05-16 11:06 ` [PATCH 02/12] drm/syncobj: add drm_syncobj_fence_lookup Julian Orth
2026-05-16 11:06 ` [PATCH 03/12] drm/syncobj: make drm_syncobj_array_wait_timeout public Julian Orth
2026-05-16 11:06 ` [PATCH 04/12] drm/syncobj: add drm_syncobj_register_eventfd Julian Orth
2026-05-16 11:06 ` [PATCH 05/12] drm/syncobj: have transfer functions accept drm_syncobj directly Julian Orth
2026-05-16 11:06 ` [PATCH 06/12] drm/syncobj: add drm_syncobj_transfer Julian Orth
2026-05-16 11:06 ` [PATCH 07/12] drm/syncobj: add drm_syncobj_timeline_signal Julian Orth
2026-05-16 11:06 ` [PATCH 08/12] drm/syncobj: add drm_syncobj_query Julian Orth
2026-05-16 11:06 ` [PATCH 09/12] drm/syncobj: fix resource leak in drm_syncobj_import_sync_file_fence Julian Orth
2026-05-16 11:06 ` [PATCH 10/12] drm/syncobj: add drm_syncobj_import_sync_file Julian Orth
2026-05-16 11:06 ` [PATCH 11/12] drm/syncobj: add drm_syncobj_export_sync_file Julian Orth
2026-05-16 11:06 ` [PATCH 12/12] misc/syncobj: add new device Julian Orth
2026-05-16 11:37 ` Greg Kroah-Hartman
2026-05-16 11:38 ` Greg Kroah-Hartman
2026-05-16 12:08 ` Julian Orth
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=20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com \
--to=ju.orth@gmail.com \
--cc=airlied@gmail.com \
--cc=arnd@arndb.de \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=skhan@linuxfoundation.org \
--cc=sumit.semwal@linaro.org \
--cc=tzimmermann@suse.de \
--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