[SOLVED] Backlight folder is suddenly empty

jvmcarneiro · 2018-04-23 04:02:34

I just booted up a regularly-updated Lenovo S400 (which backlighting I've never had to configure) to find its backlight controls not working and its /sys/class/backlight folder empty, with no relevant device available for symlinking:

#  find /sys/ -type f -iname '*brightness*'
/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/leds/ath9k-phy0/max_brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/leds/ath9k-phy0/brightness
/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.3/3-1.3:1.0/rtsx_usb_sdmmc.0.auto/leds/mmc0::/max_brightness
/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.3/3-1.3:1.0/rtsx_usb_sdmmc.0.auto/leds/mmc0::/brightness
/sys/devices/platform/i8042/serio0/input/input3/input3::scrolllock/max_brightness
/sys/devices/platform/i8042/serio0/input/input3/input3::scrolllock/brightness
/sys/devices/platform/i8042/serio0/input/input3/input3::capslock/max_brightness
/sys/devices/platform/i8042/serio0/input/input3/input3::capslock/brightness
/sys/devices/platform/i8042/serio0/input/input3/input3::numlock/max_brightness
/sys/devices/platform/i8042/serio0/input/input3/input3::numlock/brightness
/sys/module/video/parameters/brightness_switch_enabled
/sys/module/i915/parameters/invert_brightness

Big recent changes were the linux 4.16 upgrade and zsh installation. Here's my pacman history in chronological order for reference.

So I far did:

Install linux-lts
Go back to bash
Include acpi_backlight=video, vendor, native and none, as well as acpi_osi= to kernel parameters

Only acpi_backlight=vendor and acpi_osi= resulted in an interface showing in /sys/class/backlighting, but with a quite dim screen and low max brightness of about 15 with keyboard controls still not working.

journalctl -b shows no mention to brightness, backlight, light or bright.

I've also noticed in the news that glibc and pam may require manual intervention. Could it be related? I'm not sure what to do about it.

It might be worth mentioning I almost always use this machine connected to an external monitor, so the issue can be a bit older and I just didn't notice it.

--- EDIT ---

Solved:

jvmcarneiro wrote:

loqs wrote:
https://bugs.archlinux.org/task/58296#comment168869
That did it! Your comment was incredibly clarifying, not something I'm used to when trying to solve kernel issues. Thank you.
Adding video.only_lcd=0 to the boot options solved the issue. More info on the bug page above.
Marking as solved.

Last edited by jvmcarneiro (2018-04-28 14:54:56)

lz3060 · 2018-04-25 09:23:36

Same here. With or without external monitor. Trying different `acpi_backlight=` kernel values didn't help at all -- `/sys/class/backlight` remained empty.

This is on a Dell XPS 13 dev edition.

Trilby · 2018-04-25 11:27:52

To narrow your search, this could only be due to the kernel, kernel modules, and kernel command line options. Your shell, libc, and pam certainly are not relevant.

You say the problem appeared with linux 4.16, correct? Yet the lts kernel didn't fix it? That seems very odd. Are you sure you booted into the lts kernel after it was installed? If you actually did, and the /sys/ interfaces were still not as expected, the relevant change to 4.16 must have been backported to the 4.14 lts which just seems unlikely to me.

Another test would be simply to downgrade the linux package to an earlier version either from your package cache, or from the arch archive.

jvmcarneiro · 2018-04-26 06:53:06

Yeah, weird, right? But downgrading to linux 4.14.15-1 actually did it! /sys/ is now inhabited by acpi_video0 and brightness goes up to a max of 100 (in contrast to 15 before).

Before downgrading I did:
- run acpi_osi=Linux and acpi_osi='!Windows_2012' kernel parameters;
- try installing lts kernel and headers again, running grub-mkconfig after;
- try installing linux-headers

Only the acpi_osi= "!Windows_2011" one did something. Like a few other parameters, it gave me back controls, but for a max brightness of only 15.

What should I do now? File a bug? I'm not very experienced with kernel issues.

ewaller · 2018-04-26 14:02:19

I really think Trilby had the answer -- at least we should check it out before declaring that you have found a bug.

I seems likely that the kernel that was loaded by the booloader was not the same one that was installed. Try this, reinstall the latest kernel, reboot, and compare the ouitput of uname -a and of pacman -S linux (or the name of the kernel you are using if not the stock kernel). Ensure that the versions agree. If they do, and there is no backlight, then you have found something. If not, we need to fix your system configuration.

lz3060 · 2018-04-26 17:29:31

Yeah, I'm on the same boat, and it looks like a bug to me. No kernel option gives me back anything in `/sys/class/backlight`, which is stuck at (maybe) full brightness. The installed kernel, also reported by `uname -r` is `4.16.4-1-ARCH`. I have not tried downgrading yet, hoped I wouldn't have to.

loqs · 2018-04-26 22:01:20

possibly related https://bugs.archlinux.org/task/58296

jvmcarneiro · 2018-04-27 02:19:15

ewaller wrote:

I seems likely that the kernel that was loaded by the booloader was not the same one that was installed.

Seems unlikely to me, as I always uninstall the previous kernel before updating my grub config and rebooting (that's what I'm supposed to do right?). But yeah, I can do that one more time. I'll post about it soon.

Trilby · 2018-04-27 10:25:56

jvmcarneiro wrote:

I always uninstall the previous kernel before updating my grub config and rebooting (that's what I'm supposed to do right?)

What? That does not sound at all like something you should do. Although it's vague enough that I'm not sure exactly what you are saying. Booting a kernel other than the one installed would most likely be the result of the boot partition not being mounted (or mounted incorrectly) when the update was done.

Please describe what you mean by "uninstalling the previous kernel..." what exact commands are you running? If you mean when you switched from linux to linux-lts you also did a `pacman -R linux` that is not needed, but it would also do nothing to ensure the right kernel was booted.

The proper diagnostic is - as ewaller already posted - quite simple: check `pacman -Qs linux` and `uname -a` and see if the version numbers match.

jvmcarneiro · 2018-04-28 01:55:03

I'll be less vague then.

Downgraded linux (working):

$ pacman -Qs linux
local/linux 4.14.15-1 (base)
    The Linux kernel and modules
local/linux-headers 4.14.15-1
    Header files and scripts for building modules for Linux kernel

$ uname -a
Linux arch_notebook 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64 GNU/Linux

Current linux-lts (not working):

$ pacman -Qs linux
local/linux-lts 4.14.36-1
    The Linux-lts kernel and modules
local/linux-lts-headers 4.14.36-1
    Header files and scripts for building modules for Linux-lts kernel

$ uname -a
Linux arch_notebook 4.14.36-1-lts #1 SMP Tue Apr 24 16:24:39 CEST 2018 x86_64 GNU/Linux

Current linux (not working):

$ pacman -Qs linux
local/linux 4.16.3-1 (base)
    The Linux kernel and modules
local/linux-headers 4.16.3-1
    Header files and scripts for building modules for Linux kernel

$ uname -a
Linux arch_notebook 4.16.3-1-ARCH #1 SMP PREEMPT Thu Apr 19 09:17:56 UTC 2018 x86_64 GNU/Linux

loqs · 2018-04-28 08:54:19

https://bugs.archlinux.org/task/58296#comment168869

git log -F --grep 5928c281524fe451114e04f1dfa11246a37e859f
commit 378259c7d0a2e28176486a2bae611ef5ca5bd114
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Dec 23 19:41:47 2017 +0100

    ACPI / video: Default lcd_only to true on Win8-ready and newer machines
    
    
    [ Upstream commit 5928c281524fe451114e04f1dfa11246a37e859f ]
    
    We're seeing a lot of bogus backlight interfaces on newer machines without
    a LCD such as desktops, servers and HDMI sticks. This causes userspace to
    show a non-functional brightness slider in e.g. the GNOME3 system menu,
    which is undesirable. And, in general, we should simply just not register
    a non functional backlight interface.
    
    Checking the LCD flag causes the bogus acpi_video backlight interfaces to
    go away (on the machines this was tested on).
    
    This change sets the lcd_only option by default on any machines which
    are Win8-ready, to fix this.
    
    This is not entirely without a risk of regressions, but video_detect.c
    already prefers native-backlight interfaces over the acpi_video one
    on Win8-ready machines, calling acpi_video_unregister_backlight() as soon
    as a native interface shows up. This is done because the ACPI backlight
    interface often is broken on Win8-ready machines, because win8 does not
    seem to actually use it.
    
    So in practice we already end up not registering the ACPI backlight
    interface on (most) Win8-ready machines with a LCD panel, thus this
    change does not change anything for (most) machines with a LCD panel
    and on machines without a LCD panel we actually don't want to register
    any backlight interfaces.
    
    This has been tested on the following machines and fixes a bogus backlight
    interface showing up there:
     - Desktop with an Asrock B150M Pro4S/D3 m.b. using i5-6500 builtin gfx
     - Intel Compute Stick STK1AW32SC
     - Meegopad T08 HDMI stick
    
    Bogus backlight interfaces have also been reported on:
     - Desktop with Asus H87I-Plus m.b.
     - Desktop with ASRock B75M-ITX m.b.
     - Desktop with Gigabyte Z87-D3HP m.b.
     - Dell PowerEdge T20 desktop
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1097436
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133327
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133329
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1133646
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
$ git tag --contains 378259c7d0a2e28176486a2bae611ef5ca5bd114
v4.14.34
v4.14.35
v4.14.36
v4.14.37

jvmcarneiro · 2018-04-28 14:50:22

loqs wrote:

https://bugs.archlinux.org/task/58296#comment168869

That did it! Your comment was incredibly clarifying, not something I'm used to when trying to solve kernel issues. Thank you.

Adding video.only_lcd=0 to the boot options solved the issue. More info on the bug page above.

Marking as solved.

guggi · 2018-04-29 08:01:29

uname: Linux 4.16.5-1-zen #1 ZEN SMP PREEMPT
dmidecode -ssystem-product-name: XPS L322X
GRUB_CMDLINE_LINUX_DEFAULT="quiet video.only_lcd=0"

Thanks for linking to the bugreport! Solved the issue for me too.

Arch Linux

#1 2018-04-23 04:02:34

[SOLVED] Backlight folder is suddenly empty

#2 2018-04-25 09:23:36

Re: [SOLVED] Backlight folder is suddenly empty

#3 2018-04-25 11:27:52

Re: [SOLVED] Backlight folder is suddenly empty

#4 2018-04-26 06:53:06

Re: [SOLVED] Backlight folder is suddenly empty

#5 2018-04-26 14:02:19

Re: [SOLVED] Backlight folder is suddenly empty

#6 2018-04-26 17:29:31

Re: [SOLVED] Backlight folder is suddenly empty

#7 2018-04-26 22:01:20

Re: [SOLVED] Backlight folder is suddenly empty

#8 2018-04-27 02:19:15

Re: [SOLVED] Backlight folder is suddenly empty

#9 2018-04-27 10:25:56

Re: [SOLVED] Backlight folder is suddenly empty

#10 2018-04-28 01:55:03

Re: [SOLVED] Backlight folder is suddenly empty

#11 2018-04-28 08:54:19

Re: [SOLVED] Backlight folder is suddenly empty

#12 2018-04-28 14:50:22

Re: [SOLVED] Backlight folder is suddenly empty

#13 2018-04-29 08:01:29

Re: [SOLVED] Backlight folder is suddenly empty

Board footer