Comment 12 for bug 397617

(In reply to comment #11)
> > I don't think anyone wants to do direct ACPI access from drmmode_display.c;
> > going through /sys/class/backlight is the best approach.
> What I said is that the ACPI backlight I/F is hook up in drmmode_display.c. In
> such case when backlight brightness is changed through xrandr tool, the
> /sys/class/backlight is used.
> In fact in UMS mode when the brightness is changed through xrandr tool, the
> /sys/class/backlight is hook up in the 2D driver.
>
> > No this sounds very similar to what I'm proposing. In we should have either
> > /sys/class/backlight/acpi_video0
> > or
> > /sys/class/backlight/platform_foo (e.g. toshiba or sony specific driver)
> > or
> > /sys/class/backlight/i915 (for legacy i2c case)
> > As Matthew pointed out we'll need to make sure to prefer the ACPI or platform
> > driver (probably in platform, ACPI, i915 order) to interact properly with the
> > firmware.
> Very good idea.
> It seems that a new backlight interface should be registered in i915 driver.
> Should this also be registered in UMS mode?
> Another issue is whether the /sys/class/backlight/ should be hook up by xrandr
> tool. If it should be hook up, which should be selected when there exists
> multiple interfaces? For example: acpi_video0, i915

We may as well register it in the UMS case, as long as there are no conflicts between the way the UMS and kernel drivers are using the i2c interfaces. I think we want to avoid a situation where multiple backlight driver register, so we may need a notifier chain or some kind of mutual exclusion in the backlight code.