Re: [RFC PATCH 0/5] rust: drm: minimal KMS bindings, EDID read, rotation, HDCP defs

[Mike Lothian]

On Wed, 17 Jun 2026 at 16:11, Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
>
> Hi Mike,
>
> A few questions on the cover letter that may give context to
> readers... (for this and the other series you just sent)
>

Thanks for taking a look

> On Wed, Jun 17, 2026 at 5:02 PM Mike Lothian <mike@xxxxxxxxxxxxxx> wrote:
> >
> > It is deliberately an RFC and interim: it does NOT add safe Rust KMS
> > abstractions (CRTC/plane/connector wrappers - an active upstream effort),
> > only the raw binding surface plus the trait/visibility tweaks a driver
> > needs to call the C helpers itself.
>
> Do you mean this is not meant to go upstream?
>
> Or do you actually want to land this interim state? If so, then it
> needs to be well-justified why we would want to make this exception.

I'm aiming for this to go upstream, I'm a bit stuck though so I've
posted what I've got so far

> > drm::Device::as_raw() is made pub as a documented temporary escape hatch
> > for calling the C KMS helpers until safe wrappers exist. That is the part
> > most likely to draw objections, so it is split into its own patch (3/3):
> > the feature flags and header bindings in 1/3 and 2/3 are useful on their
> > own and can land even if the escape hatch is reworked or dropped (e.g.
> > replaced by narrow per-helper safe wrappers).
>
> Yeah... this sort of escape hatches aren't great. What is the reason
> for not directly working on safe abstractions?
>

If you're happy to give guidance I'll work on safe abstractions

> > Factored out of an out-of-tree in-kernel Rust DisplayLink DL3 dock driver
> > that drives a virtual connector and reads the dock's downstream EDID; but
> > the bindings are generic (the same path simpledrm/gud/udl use).
> > Compile-tested in-tree against drm-next.
>
> What is the use case? It is an out-of-tree driver? If so, the
> maintainers may not be able to take the code unless there is an actual
> user in-tree.
>
> Or is this driver expected to land upstream? Do you have a link to the
> source code?

Its going to be a complete driver, but I've banging my head against a
wall with the bring up

The project info is at:

https://github.com/FireBurn/vino-scripts
https://github.com/FireBurn/linux/tree/vino
and also at
https://gitlab.freedesktop.org/FireBurn/linux/-/tree/vino

I've posted these RFCs so make sure I'm going in the right direction
and haven't missed something stupid that's stopping bring up

> Thanks!
>
> Cheers,
> Miguel