Comment 9 for bug 397617

(In reply to comment #7)
> > Because we are trying to provide a unique backlight sysfs I/F for users. i.e.
> > hiding platform specific functions if the generic ACPI video interface is
> > available.
>
> In many cases it isn't, and we need to use platform specific i2c commands.
>
exposing all these I/F to userspace at the same time is dangerous.
that's why IGD OpRegion stuff is introduced because we want to control the backlight in ONE way to avoid the conflicts/asynchronization.
For example, if ACPI I/F is available, we should make sure that all the brightness switch are done via the ACPI backlight control methods.

(In reply to comment #8)
> How about exposing the ACPI backlight I/F to userland in the
> drmmode_dislay.c when the KMS mode is used? It means that the ACPI backlight
> I/F is hook up in 2D driver when it exists. Only when there is no ACPI I/F,
> other backlight control mode is exposed to xrandr. (For example:
> legacy/combo/native).
>
poking ACPI in drmmode_display.c doesn't look good.
I'd prefer something like a backlight control manager in the backlight sysfs class device driver.
I.e. all the drivers can register a set of backlight control callbacks to the backlight sysfs class device driver if they know how to change backlight.
and it's the sysfs driver that decides which callbacks to be called.
For example, only these files are exported under /sys/class/backlight:
1. brightness
2. actual_brightness
3. max_brightness
4. mode
...

we support multiple modes in sysfs backlight driver, like
1. generic (the ACPI backlight control offered by ACPI video driver)
2. platform (the platform specific ways offered by the platform driver)
3. legacy (I2C method)
...

users can switch between the control modes, but the generic mode is set by default.

Note that all these comments are against Jesse's "new backlight sysfs class device" idea. For the bug at hand, I think we should make clear why KMS makes the difference...