Messages in this thread | | | From | Matthew Garrett <> | Subject | Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8 | Date | Fri, 14 Jun 2013 17:29:48 +0000 |
| |
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@srcf.ucam.org
| |