drm/todo: Add entry about dealing with brightness control on devices with > 1 panel
Add an entry summarizing the discussion about dealing with brightness control on devices with more then 1 internal panel. The original discussion can be found here: https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdegoede@redhat.com/ Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This commit is contained in:
parent
c2d6920e98
commit
4f96b1bc15
@ -715,6 +715,74 @@ Contact: Sam Ravnborg
|
|||||||
|
|
||||||
Level: Advanced
|
Level: Advanced
|
||||||
|
|
||||||
|
Brightness handling on devices with multiple internal panels
|
||||||
|
============================================================
|
||||||
|
|
||||||
|
On x86/ACPI devices there can be multiple backlight firmware interfaces:
|
||||||
|
(ACPI) video, vendor specific and others. As well as direct/native (PWM)
|
||||||
|
register programming by the KMS driver.
|
||||||
|
|
||||||
|
To deal with this backlight drivers used on x86/ACPI call
|
||||||
|
acpi_video_get_backlight_type() which has heuristics (+quirks) to select
|
||||||
|
which backlight interface to use; and backlight drivers which do not match
|
||||||
|
the returned type will not register themselves, so that only one backlight
|
||||||
|
device gets registered (in a single GPU setup, see below).
|
||||||
|
|
||||||
|
At the moment this more or less assumes that there will only
|
||||||
|
be 1 (internal) panel on a system.
|
||||||
|
|
||||||
|
On systems with 2 panels this may be a problem, depending on
|
||||||
|
what interface acpi_video_get_backlight_type() selects:
|
||||||
|
|
||||||
|
1. native: in this case the KMS driver is expected to know which backlight
|
||||||
|
device belongs to which output so everything should just work.
|
||||||
|
2. video: this does support controlling multiple backlights, but some work
|
||||||
|
will need to be done to get the output <-> backlight device mapping
|
||||||
|
|
||||||
|
The above assumes both panels will require the same backlight interface type.
|
||||||
|
Things will break on systems with multiple panels where the 2 panels need
|
||||||
|
a different type of control. E.g. one panel needs ACPI video backlight control,
|
||||||
|
where as the other is using native backlight control. Currently in this case
|
||||||
|
only one of the 2 required backlight devices will get registered, based on
|
||||||
|
the acpi_video_get_backlight_type() return value.
|
||||||
|
|
||||||
|
If this (theoretical) case ever shows up, then supporting this will need some
|
||||||
|
work. A possible solution here would be to pass a device and connector-name
|
||||||
|
to acpi_video_get_backlight_type() so that it can deal with this.
|
||||||
|
|
||||||
|
Note in a way we already have a case where userspace sees 2 panels,
|
||||||
|
in dual GPU laptop setups with a mux. On those systems we may see
|
||||||
|
either 2 native backlight devices; or 2 native backlight devices.
|
||||||
|
|
||||||
|
Userspace already has code to deal with this by detecting if the related
|
||||||
|
panel is active (iow which way the mux between the GPU and the panels
|
||||||
|
points) and then uses that backlight device. Userspace here very much
|
||||||
|
assumes a single panel though. It picks only 1 of the 2 backlight devices
|
||||||
|
and then only uses that one.
|
||||||
|
|
||||||
|
Note that all userspace code (that I know off) is currently hardcoded
|
||||||
|
to assume a single panel.
|
||||||
|
|
||||||
|
Before the recent changes to not register multiple (e.g. video + native)
|
||||||
|
/sys/class/backlight devices for a single panel (on a single GPU laptop),
|
||||||
|
userspace would see multiple backlight devices all controlling the same
|
||||||
|
backlight.
|
||||||
|
|
||||||
|
To deal with this userspace had to always picks one preferred device under
|
||||||
|
/sys/class/backlight and will ignore the others. So to support brightness
|
||||||
|
control on multiple panels userspace will need to be updated too.
|
||||||
|
|
||||||
|
There are plans to allow brightness control through the KMS API by adding
|
||||||
|
a "display brightness" property to drm_connector objects for panels. This
|
||||||
|
solves a number of issues with the /sys/class/backlight API, including not
|
||||||
|
being able to map a sysfs backlight device to a specific connector. Any
|
||||||
|
userspace changes to add support for brightness control on devices with
|
||||||
|
multiple panels really should build on top of this new KMS property.
|
||||||
|
|
||||||
|
Contact: Hans de Goede
|
||||||
|
|
||||||
|
Level: Advanced
|
||||||
|
|
||||||
Outside DRM
|
Outside DRM
|
||||||
===========
|
===========
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user