| From: |
| Mike Lothian <mike-AT-fireburn.co.uk> |
| To: |
| rust-for-linux-AT-vger.kernel.org |
| Subject: |
| [RFC PATCH 0/2] drm/evdi: a Rust EVDI virtual display (a working KMS consumer) |
| Date: |
| Fri, 03 Jul 2026 04:02:45 +0100 |
| Message-ID: |
| <20260703030249.2949-1-mike@fireburn.co.uk> |
| Cc: |
| dri-devel-AT-lists.freedesktop.org, David Airlie <airlied-AT-gmail.com>, Simona Vetter <simona-AT-ffwll.ch>, Lyude Paul <lyude-AT-redhat.com>, Danilo Krummrich <dakr-AT-kernel.org>, Miguel Ojeda <ojeda-AT-kernel.org>, linux-kernel-AT-vger.kernel.org, Mike Lothian <mike-AT-fireburn.co.uk> |
| Archive-link: |
| Article |
evdi ("revdi" as a project) is a from-scratch Rust rewrite of DisplayLink's
out-of-tree evdi module: it presents virtual DRM/KMS displays whose scanout
is pulled by a userspace daemon over a drm_event + ioctl ABI, rather than
scanned out to local hardware. It identifies itself to userspace as "evdi"
for compatibility with the existing libevdi / DisplayLinkManager stack (an
ABI-compatible Rust rewrite of libevdi lives in the standalone project and
is not part of this posting).
Why post it as an RFC now: it is a *second, working* consumer of the safe
Rust KMS mode-object layer and the evdi/KMS bindings in the companion
series ("[RFC PATCH v2 00/18] rust: drm: safe KMS mode-object layer + evdi
bindings"). The other consumer posted alongside it, the vino DisplayLink
DL3 driver, is blocked at the dock's content-protection wall -- it never
gets the dock to engage its encrypted control plane, so it cannot prove
pixels actually flow on real hardware. evdi drives real monitors end to end
*today* under KWin/Wayland: multi-head output, live delta-damage updates,
a hardware cursor, DDC/CI, and clean teardown on unplug. So where vino
exercises this binding surface but can't demonstrate it, evdi does -- it is
the working validation of the same abstractions.
1/2 drm/kms: three fixes to the safe Rust KMS layer, shaken out while
bringing evdi up (a dangling mode_config vtable crash [RIP=0x9], a
stale-cache coherency gap in the Framebuffer::vmap() guard, and a
leaked-connector teardown). All are equally correct for vino and any
other KmsDriver.
2/2 the driver itself, under drivers/gpu/drm/evdi/.
NOT FOR MERGE AS POSTED: this depends on the not-yet-merged Rust DRM/KMS
bindings (the companion "rust: drm" series and the sync/DRM-registration
prerequisites it in turn depends on), so it does not build against mainline
as posted. It is sent to validate the binding surface with a driver that
works, and for review of the approach. Source:
https://github.com/FireBurn/linux/tree/vino
https://gitlab.freedesktop.org/FireBurn/linux/-/tree/vino
Mike Lothian (2):
drm/kms: rust: fixes for a virtual KMS consumer
drm/evdi: add the Rust EVDI virtual-display driver
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/evdi/Kconfig | 20 +
drivers/gpu/drm/evdi/Makefile | 2 +
drivers/gpu/drm/evdi/ddcci.rs | 43 +++
drivers/gpu/drm/evdi/evdi.rs | 405 ++++++++++++++++++++
drivers/gpu/drm/evdi/ioctl.rs | 248 ++++++++++++
drivers/gpu/drm/evdi/kms.rs | 589 +++++++++++++++++++++++++++++
drivers/gpu/drm/evdi/painter.rs | 199 ++++++++++
drivers/gpu/drm/evdi/uapi.rs | 210 ++++++++++
rust/kernel/drm/driver.rs | 24 +-
rust/kernel/drm/kms.rs | 12 +-
rust/kernel/drm/kms/framebuffer.rs | 24 ++
13 files changed, 1764 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/evdi/Kconfig
create mode 100644 drivers/gpu/drm/evdi/Makefile
create mode 100644 drivers/gpu/drm/evdi/ddcci.rs
create mode 100644 drivers/gpu/drm/evdi/evdi.rs
create mode 100644 drivers/gpu/drm/evdi/ioctl.rs
create mode 100644 drivers/gpu/drm/evdi/kms.rs
create mode 100644 drivers/gpu/drm/evdi/painter.rs
create mode 100644 drivers/gpu/drm/evdi/uapi.rs
--
2.55.0