Vino is an in-kernel Rust DRM/KMS driver for DisplayLink DL3 docks, developed against a Dell
Universal Dock D6000 (17e9:6006). It replaces both the EVDI module and the DisplayLinkManager
daemon with a single native kernel driver.
It works. This is an offer to collaborate, and a few questions where confirmation would save
guesswork.
What it does today
On a D6000, from modprobe vino on a fresh boot — no DisplayLinkManager, no EVDI, nothing else
loaded:
- brings the dock up cold, completes HDCP 2.2, and holds the encrypted control session with no resets;
- fetches real per-head EDID and exposes each monitor's native mode list;
- drives both heads at 2560x1440@120 simultaneously;
- implements the Walsh-Hadamard colour codec, verified byte-exact against DisplayLinkManager's own
output — 3600/3600 strips per frame;
- damage-based partial updates, hardware cursor, DPMS, rotation, monitor hotplug, suspend/resume.
revdi and Chimera
Two pieces likely of more direct interest on this tracker:
revdi is a clean reimplementation of the EVDI module in Rust that preserves the existing EVDI
userspace ABI, so current clients keep working unchanged. It additionally advertises a real cursor
plane and reports CURSOR_SET/CURSOR_MOVE to its client, which keeps the pointer out of the primary
framebuffer — the C module composites it in, so every pointer movement dirties the desktop and costs
a full frame.
Chimera is an open userspace service that takes over the control, authentication, encoding and
USB responsibilities of DisplayLinkManager, talking to revdi over that same ABI. It compiles the
kernel driver's protocol and codec sources verbatim in userspace, which also makes it a
differential oracle: it replays captured DisplayLinkManager sessions and checks the kernel builders
reproduce them byte-for-byte. That is how the codec claim above is substantiated.
Together they mean an existing EVDI/DLM setup can be replaced piecewise or wholesale.
This removes the structural blocker on upstreaming EVDI
Documentation/gpu/drm-uapi.rst is explicit that "any addition of DRM uAPI requires corresponding
open-sourced userspace patches, and those patches must be reviewed and ready for merging into a
suitable and canonical upstream project." The reasoning given is that without the source of all
userspace users, it becomes impossible to tell required behaviour from accidental artefacts of the
current implementation, and therefore impossible to change that implementation safely.
EVDI has never satisfied that, because its only consumer has been DisplayLinkManager, which is
proprietary. Chimera is a complete open-source consumer of the same ABI, so that objection no
longer applies — to EVDI itself, or to revdi as a replacement for it.
That does not make either automatically mergeable; the driver still has to stand on its own in
review. But the specific reason it could not even be proposed is gone, and it is gone whichever of
the two DisplayLink would rather see upstream. I would be glad to help with either.
Approach
Clean-room reverse engineering for interoperability. Every protocol claim in the documentation is
tied to the capture that establishes it, and refuted hypotheses are recorded alongside the confirmed
ones so the same ground is not covered twice.
Links
Rust binding patches for the USB, crypto and DRM abstractions this depends on have been posted as RFC
series to dri-devel and rust-for-linux.
Where confirmation would help
Nothing here is blocking, and none of it asks for anything confidential. But these are inferred from
a small number of decrypted messages, and getting them wrong risks driving hardware badly rather than
simply failing:
- The
id=0x48 sub=0x22 mode-set words at offsets 42, 66 and 72. Offset 42 tracks resolution;
offset 66 carries the CTA VIC plus a base byte; offset 72 is zero in every capture available here.
The derivation currently used reproduces all four decrypted messages, but four is a thin basis.
- The refresh ceiling. DisplayLinkManager programs a D6000 at 120 Hz even when the compositor
requests 180, and every attempt above 120 here has produced a dark panel. Is 120 a hardware limit
or a conservative software one?
- Which generations share the DL3 control plane.
17e9:4300 and 17e9:4301 present the same
bulk 0x02/0x84 control pair, the same HDCP message set and the same wsub=0x25 wrapper, but
their session initialisation differs from the D6000's.
Happy to share captures, decode notes or tooling with anyone who wants them, and glad to take
correction on anything above that is wrong.
Vino is an in-kernel Rust DRM/KMS driver for DisplayLink DL3 docks, developed against a Dell
Universal Dock D6000 (
17e9:6006). It replaces both the EVDI module and the DisplayLinkManagerdaemon with a single native kernel driver.
It works. This is an offer to collaborate, and a few questions where confirmation would save
guesswork.
What it does today
On a D6000, from
modprobe vinoon a fresh boot — no DisplayLinkManager, no EVDI, nothing elseloaded:
output — 3600/3600 strips per frame;
revdi and Chimera
Two pieces likely of more direct interest on this tracker:
revdi is a clean reimplementation of the EVDI module in Rust that preserves the existing EVDI
userspace ABI, so current clients keep working unchanged. It additionally advertises a real cursor
plane and reports
CURSOR_SET/CURSOR_MOVEto its client, which keeps the pointer out of the primaryframebuffer — the C module composites it in, so every pointer movement dirties the desktop and costs
a full frame.
Chimera is an open userspace service that takes over the control, authentication, encoding and
USB responsibilities of DisplayLinkManager, talking to revdi over that same ABI. It compiles the
kernel driver's protocol and codec sources verbatim in userspace, which also makes it a
differential oracle: it replays captured DisplayLinkManager sessions and checks the kernel builders
reproduce them byte-for-byte. That is how the codec claim above is substantiated.
Together they mean an existing EVDI/DLM setup can be replaced piecewise or wholesale.
This removes the structural blocker on upstreaming EVDI
Documentation/gpu/drm-uapi.rstis explicit that "any addition of DRM uAPI requires correspondingopen-sourced userspace patches, and those patches must be reviewed and ready for merging into a
suitable and canonical upstream project." The reasoning given is that without the source of all
userspace users, it becomes impossible to tell required behaviour from accidental artefacts of the
current implementation, and therefore impossible to change that implementation safely.
EVDI has never satisfied that, because its only consumer has been DisplayLinkManager, which is
proprietary. Chimera is a complete open-source consumer of the same ABI, so that objection no
longer applies — to EVDI itself, or to revdi as a replacement for it.
That does not make either automatically mergeable; the driver still has to stand on its own in
review. But the specific reason it could not even be proposed is gone, and it is gone whichever of
the two DisplayLink would rather see upstream. I would be glad to help with either.
Approach
Clean-room reverse engineering for interoperability. Every protocol claim in the documentation is
tied to the capture that establishes it, and refuted hypotheses are recorded alongside the confirmed
ones so the same ground is not covered twice.
Links
(mirrors: https://github.com/FireBurn/Vino · https://gitlab.com/FireBurn/Vino)
docs/protocol/: USB framing, control plane, HDCP, video and codecdocs/revdi-chimera.mddocs/reverse-engineering.mdRust binding patches for the USB, crypto and DRM abstractions this depends on have been posted as RFC
series to dri-devel and rust-for-linux.
Where confirmation would help
Nothing here is blocking, and none of it asks for anything confidential. But these are inferred from
a small number of decrypted messages, and getting them wrong risks driving hardware badly rather than
simply failing:
id=0x48 sub=0x22mode-set words at offsets 42, 66 and 72. Offset 42 tracks resolution;offset 66 carries the CTA VIC plus a base byte; offset 72 is zero in every capture available here.
The derivation currently used reproduces all four decrypted messages, but four is a thin basis.
requests 180, and every attempt above 120 here has produced a dark panel. Is 120 a hardware limit
or a conservative software one?
17e9:4300and17e9:4301present the samebulk
0x02/0x84control pair, the same HDCP message set and the samewsub=0x25wrapper, buttheir session initialisation differs from the D6000's.
Happy to share captures, decode notes or tooling with anyone who wants them, and glad to take
correction on anything above that is wrong.