On Fri, Jun 26, 2026 at 04:40:56PM -0500, Mario Limonciello wrote: > > > + * Drivers have to call drm_backlight_alloc() after allocating a > > > connector via > > > + * drm_connector_init(). This will automatically add a backlight device > > > to the > > > + * given connector. Drivers must then link a hardware backlight by > > > calling > > > + * drm_backlight_link() with the registered backlight_device. If no link > > > is > > > + * established, the DRM backlight property reports an empty range and > > > + * brightness changes are no-ops. > > > + */ > > > > It's not clear to me why we need to dynamically allocate them at all. If > > we're using the backlight subsystem we'll already have a handle to it. > > If we don't and want to implement something like DDC/CI, then it just > > becomes a hassle. Why not treat it like i2c, add a backlight field to > > drm_connector, and create the link at registration, add a new hook to > > set luminance, and then provide helpers to either use the backlight API, > > or anything else if the driver wants to. > > I did envision that later on we can have displays with DDC use this > infrastructure as well. But I didn't want to hold up the series > implementing that.
Oh absolutely. My point wasn't that you should support it right away, but rather that the architecture you work on would be extensible enough to accomodate for them later on. I'm exagerating, but for example having an architecture built around having a backlight device doesn't work, but having one where you have a set of helpers built around the backlight API does, because then we can easily create new helpers to deal with DDC/CI, MIPI-DCS, etc. without reworking the core part. Maxime
signature.asc
Description: PGP signature
