Re: [RFC PATCH 0/3] Initial plumbing for implementing DRM connector APIs in Rust

[Rahul Rameshbabu <sergeantsagara@protonmail.com>]

On Wed, 27 Aug, 2025 08:57:58 +0200 "Maxime Ripard" <mripard@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" <mripard@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-7d30c49fee2d@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