On Wed, 17 Jun 2026 at 16:11, Miguel Ojeda <[email protected]> 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 <[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. 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
