feat: add linux-drm-syncobj-v1 support

[ewgdg]

Adds linux-drm-syncobj-v1 support for dmabuf-backed surfaces.

• Exposes the protocol when the DRM import device supports syncobj eventfd.
• Uses syncobj acquire points as commit blockers.
• Falls back to the existing implicit dmabuf blocker path when no acquire point is pending.

Closes #843

Testing

• Ran cargo tests.
• Ran niri on DRM backend; journal shows exposing DRM syncobj protocol.
• Tested an Xwayland Proton game (Diablo IV) on an NVIDIA GPU; it previously froze and no longer freezes with this change.

Not tested:

• VT switch / suspend-resume / hotplug.

---

This PR intentionally keeps drm-syncobj support separate from the delayed-blocker / transaction cleanup work in #1449 / Smithay#1720. The acquire-point / dmabuf readiness logic is encapsulated in the dmabuf_readiness module, while the existing pre-commit hook structure stays mostly unchanged. That keeps the code shape close to the current implementation and should avoid making a future delayed-blocker / transaction cleanup harder.

[sabisho]

finally!

[mati865]

Cc previous attempt in #1792

[witchlliee]

Can't wait for fifo as well! Thank you for this.

[ewgdg]

I reviewed some of the previous attempts, including cmeissl’s work, before opening this PR. My read is that the Smithay delayed-blocker change is an elegant way to model niri’s transaction handling and reduce duplicated pre-commit hook handling, but it is orthogonal to drm-syncobj itself. I think it is valuable enough to be handled as a separate PR rather than making explicit sync depend on it.

To make the split more concrete: #1449 was opened as a PoC and tracks Smithay#1720, which changes the transaction/blocker model. That seems like a broader compositor/Smithay design change rather than a requirement for exposing linux-drm-syncobj-v1 itself. Because Smithay#1720 is still draft, tying drm-syncobj to it also ties this feature to a larger external review path.

This PR is intentionally aiming for the least intrusive path for drm-syncobj support. The acquire-point / dmabuf readiness logic is encapsulated in the dmabuf_readiness module, while the existing pre-commit hook structure stays mostly unchanged. That keeps the code shape close to the current implementation and should avoid making a future delayed-blocker / transaction cleanup harder.