On Sat, Sep 13, 2025 at 04:57:26PM +0000, Rahul Rameshbabu wrote: > On Wed, 27 Aug, 2025 08:57:58 +0200 "Maxime Ripard" <[email protected]> > wrote: > > Hi Rahul, > > > > On Wed, Aug 20, 2025 at 04:46:52AM +0000, Rahul Rameshbabu wrote: > >> On Tue, 19 Aug, 2025 11:06:40 +0200 "Maxime Ripard" <[email protected]> > >> wrote: > >> > Hi Rahul, > >> > > >> > On Mon, Aug 18, 2025 at 05:04:15AM +0000, Rahul Rameshbabu wrote: > >> >> I am working on a drm_connector scoped backlight API in Rust. I have > >> >> been > >> >> looking through Hans de Goede's previous efforts on this topic to help > >> >> guide my design. My hope is to enable backlight control over external > >> >> displays through DDC or USB Monitor Control Class while also supporting > >> >> internal panels. In parallel, I would like to improve the driver > >> >> probing/selection mechanism when there are different candidates for > >> >> driving > >> >> a backlight device. This initial RFC is mainly intended to sanity check > >> >> that the plumbing I have chosen for extending the DRM connector > >> >> functionality in Rust seems reasonable. > >> > > >> > It's a great goal, and I had that same discussion with Hans recently > >> > too, but I can't find the link between backling/DDC CI, and Rust. Can > >> > you elaborate? > >> > >> Hi Maxime, > >> > >> Sure, let me elaborate on this. You are right that plumbing DDC > >> CI/backlight support at the DRM connector level does not need to be > >> implemented in Rust. > >> > >> If we look at Hans's proposal, the suggested phase 2 was to add a > >> drm_connector helper function for plumbing a pointer to the backlight > >> device implementation. I had some model differences with regards to how > >> the API would look like, mostly stemming from concerns about providing > >> better runtime overriding of the acpi_video_get_backlight_type based > >> backlight selection. However, I am aligned with the direction of scoping > >> at the drm_connector level. I basically was interested in implementing > >> this helper functionality in Rust instead of C, which is where Rust came > >> into play. > >> > >> I was also interested in declaring and attaching a drm_property in Rust > >> for controlling properties such as backlight rather than updating the > >> drm_connector declaration in C as an experiment. > >> > >> Let me know if you feel like this work would be better off as a C > >> implementation. I can also send out a detailed architecture proposal to > >> the mailing list if that would help. > >> > >> Link: > >> https://lore.freedesktop.org/wayland-devel/[email protected]/ > > > > Thanks for the explanation. > > > > I'm not sure Rust is at the point where we can use it for the framework. > > If we want to make this work useful, we have to make it consistent and > > usable across all drivers, but we do have drivers for architectures that > > aren't supported by Rust yet (let alone tier 1). > > > > So it feels to me that it would be a bit premature for that work to be > > in Rust. If you do want to use it from a Rust driver though, feel free > > to write bindings for it, that would be a great addition. > > Hi Maxime, > > Thanks for the follow-up. Sorry for the delay in my response. I was > preparing a slide deck for Kangrejos 2025 (Rust for Linux conference). > > https://binary-eater.github.io/kangrejos-2025/ > > The above discusses the architecture I had in mind in greater detail. I > am working on some last minute tweaks. I wanted to do a couple things > with regards to this topic. > > 1. Send a high level RFC describing the architecture / functionality > 2. In parallel, maybe further evaluate whether Rust could be viable for > this effort. I hope the slides I put together help. > 3. If the discussion in point 2 seems to suggest that Rust is not > viable, do the core implementation work in C. > > Let me know if this seems like a reasonable approach and thank you so > much for taking the time to respond.
The thing I was trying to say before is that we have an inherent tension here: it's an interface we want to roll as widely as possible, otherwise userspace is going to either ignore it, or the kernel wouldn't provide a consistent interface for this. We do have drivers that are for architectures that don't have rust support yet. I still think it's premature to have code used by all those drivers in Rust just yet. Maxime
signature.asc
Description: PGP signature
