On Fri, 2013-06-14 at 14:47 +0800, Aaron Lu wrote:
What about a priority based solution? We can introduce a new field named priority to backlight_device and instead of calling another module's function like the unregister one here(which cause unnecessary module dependency), we only need to boost priority for its own interface. This field will be exported to sysfs, so user can change it during runtime too. And we can also introduce a new kernel command line as backlight.force_interface=raw/firmware/platform, to overcome the limited functionality provided by acpi_backlight=video/vendor, which does not involve GPU's interface.
How would that work with existing userspace?
And we can place the quirk code in backlight layer instead of individual backlight functionality provider module. Suppose we have a backlight manager there, for all win8 systems, we can boost the raw type's priority on its registration, so no need to add code in intel/amd/etc./'s GPU driver code.
But we'd need to add code to every piece of userspace that currently uses the backlight, right?
With priority based solution, all backlight control interfaces stay, the priority field is an indication given by kernel to user space.
We shouldn't export interfaces if we don't expect them to work.