Hi,
On 11-06-15 14:28, Jani Nikula wrote:
On Thu, 11 Jun 2015, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 11-06-15 11:19, Pali Rohár wrote:
On Wednesday 10 June 2015 15:01:07 Hans de Goede wrote:
Currently we have 2 kernel commandline options + dmi-quirks in 3 places all interacting (in interesting ways) to select which which backlight interface to use. On the commandline we've acpi_backlight=[video|vendor] and video.use_native_backlight=[0|1]. DMI quirks we have in acpi/video-detect.c, acpi/video.c and drivers/platform/x86/*.c .
This commit is the first step to cleaning this up, replacing the 2 cmdline options with just acpi_video.backlight=[video|vendor|native|none], and adding a new API to video_detect.c to reflect this.
Follow up commits will also move other related code, like unregistering the acpi_video backlight interface if it was registered before other drivers which take priority over it are loaded, to video_detect.c where this logic really belongs.
Signed-off-by: Hans de Goede hdegoede@redhat.com
Hello,
lot of people are using acpi_backlight parameter in kernel cmdline to fix some of problems. I would like to see this parameter still working and to not break existing configuration. E.g acpi_backlight=vendor to use dell-laptop.ko or thinkpad_acpi.ko backlight.
I would have like to keep acpi_backlight= for that exact same reason, but that is not possible while keeping acpi_video as a module.
Thinking more about this, this is not strictly true, we could make some other (core) part of the acpi code use __setup to get the acpi_backlight= value and have that part export the value for use in the acpi_video module. This is not really pretty, but I think it may be the best way to solve this.
It just might be a good idea to try to not change the backlight related parameters all the time... See [1]. I probably forgot a few.
Right, so as said I'm fine with adding the above work-around to the next version of the patch-set to keep acpi_backlight=[vendor|video] working as before.
Regards,
Hans