On Sat, May 16, 2026 at 1:38 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
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?
I didn't consider using rust because I'm not familiar with rust in the kernel.
But even if I had considered it, I probably would not have done it because drm_syncobj currently has no rust bindings. The driver as-is is just a thin layer around drm_syncobj.c so if drm_syncobj gains rust bindings it should be easy to convert the driver.
Just curious, not a criticism of this in C at all.
thanks,
greg k-h