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 <[email protected]> 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
