On Wed, Mar 24, 2021 at 9:31 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Tue, Mar 23, 2021 at 9:40 PM Pavel Machek <pavel@xxxxxx> wrote: > > > CC linux-leds (which I intended, but forgot to add) > > > > > > cover letter at > > > https://lore.kernel.org/linux-devicetree/20210322144848.1065067-1-geert@xxxxxxxxxxxxxx/ > > > > > + err = ht16k33_brightness_set(priv, seg->led.brightness); > > > > > if (err) > > > > > return err; > > > > > > > > The LED class can pretty much do what the backlight class can and more. > > > > > > > > Maybe we can stop registering a backlight device in the fbdev case and > > > > register a led device for both. This makes the code cleaner and drops > > > > a dependency but will break backwards compatibility. > > > > > > > > I'd prefer a single solution that covers both use cases, but I'm not > > > > sure about the 'breaking backwards compatibility' consequence... > > > > For new drivers, breaking compatibility should not be a problem. > > The dot-matrix support is part of the existing driver, thus subject to > backwards compatibility. > Perhaps we can register the LED device for both, and build the backlight > device on top of the LED device, like "led-backlight" does. Would that > work? Or can't the LED no longer be controlled from sysfs (e.g. > triggers) if it is in use by a backlight driver? Using "led-backlight", the backlight can no longer be controlled from sysfs, precluding the use of other triggers incl. hardware blinking. But a normal LED can be used as a backlight, with ledtrig-backlight, so that is the most flexible option, but only if no backwards compatibility is to be considered. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
