Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König <[email protected]>: > > 1. This series makes the ability to manipulate syncobjs available > > independently of attached hardware. > > 2. It makes it available under a consistent path /dev/syncobj. > > Exactly that is a big no-go. This has to be under /dev/dri. FWIW udmabuf is also under /dev directly, but I don't think any compositor developer would complain about a different path. What are the rules for that? Could this simply be put in /dev/dri/syncobj?
The part where we get this independent of attached hardware is quite important for us though, since we can't just ignore explicit sync once the device we previously imported the syncobj into is disconnected. Buffers can be from any device or allocated in system memory and access should be synchronized properly in all cases. How exactly it's made available isn't all that critical. > > 3. It removes the need to translate between syncobjs fds and handles. > > That's a pretty big no-go as well. The differentiation between FDs and > handles is completely intentional. Could you expand on why it's needed? For compositors, the handle is just an intermediary thing when translating between file descriptors. FTR for me at least, this part would be merely nice to have, since it slightly reduces the amount of ioctls a compositor needs to call, but it's not important. > >> What about using VGEM for this? > > > > If the vgem render node were made available unconditionally under, > > Software rendering is a complete corner case, I don't think that this will be > enabled by default. That simply makes vgem unsuitable for solving the problems we face in compositors. - Xaver
