[RFC] drm/kms: control display brightness through drm_connector properties

[Daniel Vetter]

On Fri, Apr 08, 2022 at 12:26:24PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 4/8/22 12:16, Simon Ser wrote:
> > Would it be an option to only support the KMS prop for Good devices,
> > and continue using the suboptimal existing sysfs API for Bad devices?
> > 
> > (I'm just throwing ideas around to see what sticks, feel free to ignore.)
> 
> Currently suid-root or pkexec helpers are used to deal with the
> /sys/class/backlight requires root rights issue. I really want to
> be able to disable these helpers at build time in e.g. GNOME once
> the new properties are supported in GNOME.  So that distros with
> a new enough kernel can reduce their attack surface this way.

Yeah but otoh perpetuating a bad interface forever isn't a great idea
either. I think the pragmatic plan here is
- Implement this properly on good devices, i.e. anything new.
- Do some runtime disabling in the pkexec helpers if they detect a modern
  system (we should be able to put a proper symlink into the drm sysfs
  connector directories, to make this easy to detect). It's not as great
  as doing this at compile time, but it's a step.
- Figure out a solution for the old crap. We can't really change anything
  with the load ordering for existing systems, so if the hacked-up compat
  libbacklight-backlight isn't an option then I guess we need some quirk
  list/extracted code which makes i915/nouveau/radeon driver load fail
  until the right backlight shows up. And that needs to be behind a
  Kconfig to avoid breaking existing systems.

Inflicting hotplug complications on all userspace (including uevent
handling for this hotpluggable backlight and everything) just because
fixing the old crap systems is work is imo really not a good idea. Much
better if we get to the correct future step-by-step.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch