On Wed, 27 Aug, 2025 08:57:58 +0200 "Maxime Ripard" <mrip...@kernel.org> 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" <mrip...@kernel.org> >> 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/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ > > 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. Thanks, Rahul Rameshbabu > > Maxime
