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. -- Matthew Garrett | mjg59 at srcf.ucam.org
