Hi, On 06/10/2014 06:17 PM, Matthew Garrett wrote: > On Tue, 2014-06-10 at 16:16 +0000, Matthew Garrett wrote: >> On Thu, 2014-05-15 at 11:39 +0200, Hans de Goede wrote: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1097436 >> >> I'm not especially keen on this - if this seems like a general problem, >> adding boards piecemeal to a DMI table will never solve it for most >> people. What does performing the backlight calls actually do? > > Or, alternatively, check the DMI chassis type and just skip desktop > boards?
That might work, note that part of the problem is the BIOS exporting an acpi-video interface. So we would either need to do this check in the acpi-video driver, or alternatively do it in the asus-wmi driver and call acpi_video_dmi_promote_vendor() when the check fails. I'm not 100% sold on adding this check in general, because it assumes that the chassis type will be reliable, which seems like a long shot, ie what if an all in one, with a backlight, uses 3 / Desktop as chassis type ? Note that once the acpi-video interface is disabled by using e.g. acpi_backlight=vendor, then the asus-wmi driver will create a backlight control with a max_brightness of 0, which seems like a bug in the asus-wmi driver. I did not do a patch for this because I was afraid that not registering the asus-wmi brightness control when the max_brightness == 0 might cause regressions (e.g. it will also remove the bl_power function, what if in some cases max_brightness == 0, but we want / need bl_power ?) . Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
