[PATCH resend 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backlight

Hans de Goede hdegoede at redhat.com
Thu May 22 01:41:44 PDT 2014


On 05/22/2014 01:30 AM, Rafael J. Wysocki wrote:
> On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
>> acpi_video_backlight_support() is supposed to be called by other (vendor
>> specific) firmware backlight controls, not by native / raw backlight controls
>> like nv_backlight.
>> Userspace will normally prefer firmware interfaces over raw interfaces, so
>> if acpi_video backlight support is present it will use that even if
>> nv_backlight is registered as well.
>> Except when video.use_native_backlight is present on the kernel cmdline
>> (or enabled through a dmi based quirk). As the name indicates the goal here
>> is to make only the raw interface available to userspace so that it will use
>> that (it only does this when it sees a win8 compliant bios).
>> This is done by:
>> 1) Not registering any acpi_video# backlight devices; and
>> 2) Making acpi_video_backlight_support() return true so that other firmware
>> drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
>> own vender specific interfaces.
>> Currently nouveau breaks this setup, as when acpi_video_backlight_support()
>> returns true, it does not register itself, resulting in no backlight control
>> at all.
>> This is esp. going to be a problem with 3.16 which will default to
>> video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
>> will get no backlight control at all.
>> This also likely explains why the previous attempt to make
>> video.use_native_backlight=1 the default was not a success, as without this
>> patch having a default of video.use_native_backlight=1 will cause regressions.
>> Note this effectively reverts commit 5bead799
>> Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171
>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
> It would be good to have an ACK from the nouveau people for this one.

Right, it could / should even go in through the drm tree I guess.



More information about the dri-devel mailing list