On Sat, May 16, 2026 at 01:06:15PM +0200, Julian Orth wrote:
This device makes the DRM_IOCTL_SYNCOBJ_* ioctls available via a dedicated device. This allows applications to use syncobjs without having to open device nodes in /dev/dri, on systems that don't have any such nodes, or on systems whose devices don't support the DRIVER_SYNCOBJ_TIMELINE feature.
Wayland uses syncobjs as its buffer synchronization mechanism. Most compositors use the DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to perform a pure CPU wait for syncobj point. DRM devices are not involved in this process except insofar that a DRM device needs to be used to access the ioctl.
Similarly, a software-rendered client might perform rendering on a dedicated thread and use the wayland syncobj protocol to submit frames before they finish rendering. Again, this does not involve DRM devices except insofar ... as above.
As an added benefit, this device removes the need to translate between file descriptors and handles.
Signed-off-by: Julian Orth ju.orth@gmail.com
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 + drivers/misc/Kconfig | 10 + drivers/misc/Makefile | 1 + drivers/misc/syncobj.c | 404 +++++++++++++++++++++ include/uapi/linux/syncobj.h | 75 ++++ 5 files changed, 491 insertions(+)
As this is a bunch of user-facing code, why not do this in rust to at least get some semblance of proper parsing of user data sanity? Or is the api to the drm layer just to complex for that at the moment?
Just curious, not a criticism of this in C at all.
thanks,
greg k-h