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

[Miguel Ojeda]

Hi Mike,

A few questions on the cover letter that may give context to
readers... (for this and the other series you just sent)

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.

> 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?

> 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?

Thanks!

Cheers,
Miguel