Hi,
Thank you for your input and for the quick reply.
On 15-05-19 00:42, João Paulo Rechi Vita wrote:
Hello Hans, thanks for reaching out.
On Tue, May 14, 2019 at 1:23 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Hi João, All,
I've been helping a Fedora user debugging a problem where the backlight turns off and
never turns on again with newer kernels:
https://bugzilla.redhat.com/show_bug.cgi?id=1697069
At this point I'm pretty sure this commit is the culprit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=78f3ac76d9e5
The breakage happens between 4.20.4 and 4.20.5 and that commit is the only one
standing out; and blacklisting eeepc-wmi fixes things.
For now I'm going to add a new DMI quirk for this (patch for this will follow later)
but this is something to keep in mind if we get more reports about backlight/display
breakage on eeepc laptops. I'm thinking that maybe the new behavior introduced
by commit 78f3ac76d9e5 should only be applied to laptops using
asus-nb-wmi and not to laptop using eeepc-wmi (the code modified
by the commit is common to both drivers).
Actually there was another report from a user via private email with
similar symptoms on a Asus Eee PC 1015BX -- no backlight after
starting the kernel (probably after eeepc-wmi is probed) -- which I've
been meaning to reply for a couple of weeks now, so I'm also cc'ing
others involved in that thread.
Hmm, that one is using an AMD CPU + graphics, so it indeed seems that
this impacts multiple devices using eeepc-wmi and is not limited to
just Intel Cedar Trail machines.
In that case the user was able to work
around the problem by passing acpi_backlight=vendor, just to add an
extra datapoint.
Right, that is logical, because the problematic commit adds the else of
this bit of code:
if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
err = asus_wmi_backlight_init(asus);
if (err && err != -ENODEV)
goto fail_backlight;
} else
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
And passing acpi_backlight=vendor makes the if condition true, so it never
executes the line added by commit 78f3ac76d9e5.
João, can you check if the 11 models mentioned in the commit msg
(or a bunch of similar models you have access too) are using asus-nb-wmi;
or eeepc-wmi ?
All of the 11 models where we saw this problem are using asus_nb_wmi:
E203NAS, GL553VE, X441NC, X441UVK, X541UVK, X555DG, X555UB, X555UQ,
X560UD, X570ZD, X705FD.
Furthermore, from the 144 Asus models we have in our database at
Endless, only 10 probe the eeepc_wmi module: D320SF-K, D415MT, D520MT,
D640SA, D830MT, G11DF, V221ID, V272UN, ZN220IC-K, ZN241IC.
6 out of these 10 also probe asus_nb_wmi: D640SA, G11DF, V221ID,
V272UN, ZN220IC-K, ZN241IC.
And the 4 that only probe eeepc_wmi are all desktop models: D320SF-K,
D415MT, D520MT, D830MT.
I agree with limiting this behavior to asus-nb-wmi only on mainline --
it will still apply to the original affected hardware, and it is much
better than keep updating a list of DMI quirks. We will also need to
send it to a few linux-stable branches as well.
I agree that given the new info it indeed seems to best to only do
the asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL) call
when the asus_nb_wmi driver is loaded, I will prepare a patch for
this with a fixes tag pointing to commit 78f3ac76d9e5.
Regards,
Hans
