Backlight background and solution

backlight

i. Some background on backlight control:

For a laptop, there usually are three sources to control backlight:
one from video module's ACPI interface;
one from x86 platform driver's ACPI interface;
one from GPU driver's native interface.

All of them will register a backlight device, which will create a sysfs
interface under /sys/class/backlight for users to control, they are
identified by their type:
video module's backlight is of type FIRMWARE;
platform module's backlight is of type PLATFORM;
GPU module's backlight is of type RAW.

Since there are three interfaces, user space tool will pick one to use.
The gnome-settings-daemon tool used on GNOME has the following
preference order: FIRMWARE > PLATFORM > RAW.
So if a laptop model has all of these interfaces, the video module'
interface will be used; if it only has gpu's interface, then the gpu's
interface will be used.

On systems that do not make use of g-s-d, the xorg driver has a preference
list too. For example, the xorg-x11-drv-intel has the following list:
static const char *backlight_interfaces[] = {
	"gmux_backlight",
	"asus-laptop",
	"asus-nb-wmi",
	"eeepc",
	"thinkpad_screen",
	"mbp_backlight",
	"fujitsu-laptop",
	"sony",
	"samsung",
	"acpi_video1", /* finally fallback to the generic acpi drivers */
	"acpi_video0",
	"intel_backlight",
	NULL,
};
It lists all known interfaces and tries to use any of them if they exist.

The problem is, the preferred interface does not always work. When it
doesn't, someone has to do something. Currently, there are two ways to
do this:
i) there is a DMI table in video_detect.c; adding an entry there would
make acpi video module not creating backlight interface for the
afftected systems, while notification functionality is not affected;
ii) Some platform driver have backlight management capability, they have
a DMI table, where only specific models belong to a vendor are listed,
e.g. acer-wmi module have a DMI table that lists all acer related models
that have broken acpi video control interface. For laptop models in this
table, the platform driver can do things accordingly like unregistering
acpi video module and not creating backlight interface their own or
whatever they see appropriate.

This is how we work around bugs for now.

ii. The problem

Then we have a new type bug: for some laptop models, neither the ACPI
video module nor the platform driver provides a working backlight
interface - the only working interface is provided by GPU. For hotkey
notification, ACPI video's handler is required.

So we have a problem here - for platform drivers that have no backlight
management capability, we can only make the backlight interface
provided by ACPI video go away with the DMI table in video_detect.c but
the platform driver's interface is still there unless we add some code
for it; for platform drivers that have backlight management capability,
we will need to add new functions to ACPI video module to make it possible
for them to only remove backlight interface while keeping the notification
handler(already done by Lee Chun-Yi).

As you can see, we don't have a clean way to easily select which
backlight interface + which backlight notification handler for a
specific system.

iii. The proposed solution

For this matter, We would like to introduce a new field called
priority to the backlight interface to express to user space, of
the available interfaces, which has the best chance of working.

By default, we will impose a default priority order as:
firmware > platform > raw.

For a category of systems(like the win8 laptops, where ACPI video's
interface has little chance of working, don't know much about platform's
interface but from the bug, they don't work either), we can boost
raw type's priority since according to a MS' document, it is possible
OEM doesn't test ACPI interface well on those laptops. And for other
categories, we can change individual type's priority as needed.

A kernel command line is to be added, something like
backlight=raw/firmware/platform to let user decide which interface
should have the highest priority on his system.

Since the new priority field will also be exported in sysfs interface,
user can also change the value as he see fits during runtime.

And all these priority related handling is supposed to be located in
backlight layer, i.e. drivers/video/backlight_*.c. Helper APIs will be
provided there, so that every backlight control interface provider
module does not need to depend on each other to do things like
unregistering other module's interface, etc.

The addition of priority field will require user space tool making
modifications, sadly(I have example patch for intel xorg driver, not
much changes needed).