[SOLVED] After xorg-server update backlight is not behaving

mcloaked · 2014-07-29 18:38:53

After updating a Thinkpad S540 today the system goes into dim backlight level for the screen during the initial stages of the boot process, and recovers to normal brightness after the password has been entered in the KDM greeter and the user logs in to KDE. Running KDE the brightness behaves normally, but when the system shuts down after logging out from KDE the text output during shutdown does into very dim mode again.

The brightness parameters when logged in to KDE look fine.

$ ls -1 /sys/class/backlight/intel_backlight/*brightness | xargs -I % sh -c "echo % ; cat %"
/sys/class/backlight/intel_backlight/actual_brightness
937
/sys/class/backlight/intel_backlight/brightness
937
/sys/class/backlight/intel_backlight/max_brightness
937
$ ls -1 /sys/class/backlight/acpi_video0/*brightness | xargs -I % sh -c "echo % ; cat %"
/sys/class/backlight/acpi_video0/actual_brightness
100
/sys/class/backlight/acpi_video0/brightness
100
/sys/class/backlight/acpi_video0/max_brightness
100

The snippet of journal log relevant to the brightness setting is:

Jul 29 17:56:28 lenovo1 systemd[1]: Created slice system-systemd\x2dbacklight.slice.
Jul 29 17:56:28 lenovo1 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0...
Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.25
Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: http://ibm-acpi.sf.net/
Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: ThinkPad BIOS GPET58WW (1.58 ), EC unknown
Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: Lenovo ThinkPad S5-S540, model 20B3CTO1WW
Jul 29 17:56:28 lenovo1 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:intel_backlight...
Jul 29 17:56:28 lenovo1 kernel: snd_hda_intel 0000:00:1b.0: irq 61 for MSI/MSI-X
Jul 29 17:56:28 lenovo1 kernel: tpm_tis 00:0b: 1.2 TPM (device-id 0x0, rev-id 78)
Jul 29 17:56:28 lenovo1 kernel: ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure, AE_NOT_FOUND (20
Jul 29 17:56:28 lenovo1 kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.RP05.PEGP.DD02._BCL] (Node f
Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: detected a 8-level brightness capable ThinkPad
Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, suppo
Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
Jul 29 17:56:28 lenovo1 systemd-backlight[200]: Saved brightness 11 too low; increasing to 46.
Jul 29 17:56:28 lenovo1 kernel: snd_hda_intel 0000:00:03.0: irq 62 for MSI/MSI-X
Jul 29 17:56:28 lenovo1 kernel: ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20140
Jul 29 17:56:28 lenovo1 kernel: ACPI Error: Method parse/execution failed [\_TZ_.TZ01._TMP] (Node ffff880226839cd0
Jul 29 17:56:28 lenovo1 kernel: ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20140
Jul 29 17:56:28 lenovo1 kernel: ACPI Error: Method parse/execution failed [\_TZ_.TZ01._TMP] (Node ffff880226839cd0
Jul 29 17:56:28 lenovo1 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:acpi_video0.
Jul 29 17:56:28 lenovo1 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.

Booting with kernel parameter systemd.restore_state=0 gives a normal brightness throughout. So this must have something to do with the saving of the brightness parameters by systemd. The clue is in the journal log above:

systemd-backlight[200]: Saved brightness 11 too low; increasing to 46.

I wonder how I can get systemd to reset the stored value which is too low to be sensible?

Has anyone seen similar behaviour and if so is there a proper fix instead of the workaround in the bug I have filed upstream as below?

Filed arch bug https://bugs.archlinux.org/task/41390
and upstream at https://bugs.freedesktop.org/show_bug.cgi?id=81884

Last edited by mcloaked (2014-08-13 08:58:01)

amish · 2014-07-30 02:29:28

Same issue in HP 4510s laptop. Brightness seems to be randomly set.

Once I noticed low brightness when shutdown. Then once KDE brightness was low.

But when I again restarted laptop it seemed to work ok.

mcloaked · 2014-07-30 13:32:54

It looks like systemd is not storing the brightness values correctly so maybe xf86-video-intel is involved as well as systemd? Anyway I checked the values that systemd stored and they look as follows:

# cat /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:acpi_video0 
100
# cat /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight 
11

So the value in intel_backlight is certainly incorrect - the above values were checked after KDE resets the brightness correctly. So the numbers in the /sys/ area are set right but on shutdown it seems that the saved values by systemd are wrong:

# ls -1 /sys/class/backlight/*/*brightness | xargs -I % sh -c "echo % ; cat %"
/sys/class/backlight/acpi_video0/actual_brightness
100
/sys/class/backlight/acpi_video0/brightness
100
/sys/class/backlight/acpi_video0/max_brightness
100
/sys/class/backlight/intel_backlight/actual_brightness
937
/sys/class/backlight/intel_backlight/brightness
937
/sys/class/backlight/intel_backlight/max_brightness
937

These values are not getting saved by systemd but the intel value is somehow becoming 11 instead of 937

wwn · 2014-07-30 16:39:56

same here (T420s):

18:40:01^wwn@~$ sudo  ls -1 /sys/class/backlight/*/*brightness | xargs -I % sh -c "echo % ; cat %"
/sys/class/backlight/acpi_video0/actual_brightness
11
/sys/class/backlight/acpi_video0/brightness
11
/sys/class/backlight/acpi_video0/max_brightness
15
/sys/class/backlight/acpi_video1/actual_brightness
11
/sys/class/backlight/acpi_video1/brightness
15
/sys/class/backlight/acpi_video1/max_brightness
15
/sys/class/backlight/intel_backlight/actual_brightness
1774
/sys/class/backlight/intel_backlight/brightness
1774
/sys/class/backlight/intel_backlight/max_brightness
4437

mcloaked · 2014-07-30 21:39:35

It was suggested in the arch bug referred above that the solution was probably due to an xf86-video-intel bug. I was asked to try this fix:
http://cgit.freedesktop.org/xorg/driver … 0d681c171e

Building the package with the patch initially did not resolve the problem when rebooting.

However after doing a pacman update that included upgraded kdelibs (4.13.3-1 -> 4.13.3-2), and then shutting down completely and booting from cold seems to have resolved the issue! I checked the stored brightness value which is at /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight and it now gives 937 which is correct!

I tested by reverting the xf86-video-intel package to that in [core] and the problem with brightness returned. Re-installing the amended package containing the patch http://cgit.freedesktop.org/xorg/driver … 0d681c171e fixes the issue again. So indeed the patch does fix the problem. Whether additionally I needed to fully shutdown and boot from cold only, or whether the additional update to kdelibs was crucial I don't know, but with both the version 4.13.3-2 of kdelibs as well as the patched xf86-video-intel this seemed to be resolved for me now.

However after shutting down the laptop I noticed the problem had recurred - on booting up the same symptoms are there - so this needs more work to fix this bug.

Last edited by mcloaked (2014-07-30 21:49:49)

interstellar · 2014-08-01 03:16:58

Similar issue here on a lenovo yoga 2 pro laptop. The difference is that brightness is set to maximum at each boot, as well as after each relogin. I'm working with Gnome and gdm as the login manager.

Last edited by interstellar (2014-08-01 03:21:40)

mkoskar · 2014-08-01 20:18:50

I thought I start a new thread, but reading this one I believe it's the same issue as the one I'm trying to solve.
I would summarize my observations differently though.

Boot.
Systemd restores values of 'acpi_video0' / 'intel_backlight' correctly.
Log into vc1.
Change backlight by writing to 'acpi_video0' or 'intel_backlight' (both work for me).
Start X session by "startx" like script manually.
Backlight is kept as set in vc1 before.

But now, whenever I switch to other virtual console, or I just quit X, brightness is reset.
It would just all be fine if X server (or probably the driver for that matter) wouldn't do anything and just keep the brightness as is.

I've tried to play with X server "intel"'s driver "Backlight" setting without any success.
E.g. having backlight set to '10' via 'acpi_video0' in X I get:

/sys/class/backlight/acpi_video0: 10 from 15
/sys/class/backlight/intel_backlight: 1287 from 4437

Switching to vc2 (having started X with "Backlight" "acpi_video0") I get:

/sys/class/backlight/acpi_video0: 15 from 15
/sys/class/backlight/intel_backlight: 52 from 4437

and screen is dimmed to reflect the "52" above.

Switching to vc2 (having started X with "Backlight" "intel_backlight") I get:

/sys/class/backlight/acpi_video0: 10 from 15
/sys/class/backlight/intel_backlight: 4437 from 4437

here the screen is reset to full brightness.

Everytime when I switch back to X virtual console, brightness is reset to the value which was set there before (just before switching to text virtual console) or the new one which was manually set in virtual console by writing to 'acpi_video0' or 'intel_backlight'.

Booting with "video.use_native_backlight=1 acpi_backlight=vendor" doesn't make any difference in regars to this issue.

Last edited by mkoskar (2014-08-01 20:25:54)

mcloaked · 2014-08-01 22:11:43

mkoskar: is it worth adding your information to the arch bug I referenced in comment #1? Any diagnostics and additional data should help the developers find a solution and the best place to get communication with the developers is in the arch bug report.

mkoskar · 2014-08-01 22:25:23

mcloaked wrote:

mkoskar: is it worth adding your information to the arch bug I referenced in comment #1? Any diagnostics and additional data should help the developers find a solution and the best place to get communication with the developers is in the arch bug report.

That's right, somehow missed on that .

OB4Life · 2014-08-07 09:06:02

Hi. I have a Thinkpad R400. Coincidentally this problem started occurring just after a fitted a new LCD panel and so i had thought it was related. Now, i am not so sure; as my problem is much like yours: screen dims during logout and shutown, and annoyingly the brightness doesn't ratchet back up after a login and has to be done manually.

Anyways, adding the "acpi_backlight=vendor" to /etc/default/grub fixed the screem dimming for me. So that:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_backlight=vendor"

However, now the screen is set to maximum brightness after a reboot or login, irrespective of the prior state. This is an improvement over being set to near minimal brightness, however, and will do for now, for me. Though i Will be watching this thread.

By the way i got that kernel parameter from the wiki page concerning Intel graphics, under the heading Backlight is not Adjustable. So i guess that potentialy suggests Intel driver over systemd as at fault.

https://wiki.archlinux.org/index.php/In … adjustable

Cheers.

mcloaked · 2014-08-07 16:46:20

OB4Life wrote:

Hi. I have a Thinkpad R400. Coincidentally this problem started occurring just after a fitted a new LCD panel and so i had thought it was related. Now, i am not so sure; as my problem is much like yours: screen dims during logout and shutown, and annoyingly the brightness doesn't ratchet back up after a login and has to be done manually.
Anyways, adding the "acpi_backlight=vendor" to /etc/default/grub fixed the screem dimming for me. So that:
GRUB_CMDLINE_LINUX_DEFAULT="acpi_backlight=vendor"
However, now the screen is set to maximum brightness after a reboot or login, irrespective of the prior state. This is an improvement over being set to near minimal brightness, however, and will do for now, for me. Though i Will be watching this thread.

That is worth trying I guess for me - though it was working fine without the need to add kernel parameters prior to the problematic updates!

Edit: Using the kernel parameter suggestion makes no difference to this issue on my laptop. So I guess the bug I am seeing is different to that reported in the previous post.

Last edited by mcloaked (2014-08-07 20:24:34)

mcloaked · 2014-08-13 08:57:35

After today's kernel update to 3.16.0-2-ARCH the brightness issue is resolved for me so I will now mark this as solved. So this was presumably a kernel bug that had a patch fixing the issue in the 3.16 kernel.

ssri · 2014-08-13 18:15:35

Thanks for the bug report. It was pretty disorienting to return to a nearly dark screen after exiting my DE. Thankfully I found this thread and waited for the release of the appropriate fix. Everything is back to normal (for the most part).

iskandr · 2014-08-13 21:45:10

mcloaked wrote:

After today's kernel update to 3.16.0-2-ARCH the brightness issue is resolved for me so I will now mark this as solved. So this was presumably a kernel bug that had a patch fixing the issue in the 3.16 kernel.

Whatever they changed in this kernel update to fix your backlight issue, it broke the backlight controls on my old HP 550. I can't control the brightness level via fn key + f7/f8 anymore (which always used to work) and my system now always starts with the lowest brightness level (changed brightness levels trough various methods are not restored on reboot), so it's hard to see anything at all. I know there are workarounds, but this is just annoying, since i adjust brightness levels quite a lot and it always used to work. I don't even know if this is related to this issue here, but since apparently they changed something in the way backlight settings behave, I assume it is.

kelloco2 · 2014-08-13 22:07:06

at me the same way. Asus K75VJ . I can controll by e.g.

echo "3000" >> /sys/class/backlight/intel_backlight/brightness

but acpi hotkeys stopped working. (fn + f5/f6). others acpi hotkeys works good. I do not know if this is a bug. xmodmap recognizes my keys, so installing acpid and setting handlers for bash scripts about "echo $(cat /sys/class/backlight/intel_backlight/brightness - $(/sys/class/backlight/intel_backlight/brightness / 100) /> / sys / class" etc ... it could fix it, but I prefer to wait for a future update, because I do not want to write the script.

iskandr · 2014-08-13 22:19:15

kelloco2 wrote:

at me the same way. Asus K75VJ . I can controll by e.g.
echo "3000" >> /sys/class/backlight/intel_backlight/brightness
but acpi hotkeys stopped working. (fn + f5/f6). others acpi hotkeys works good. I do not know if this is a bug. xmodmap recognizes my keys, so installing acpid and setting handlers for bash scripts about "echo $(cat /sys/class/backlight/intel_backlight/brightness - $(/sys/class/backlight/intel_backlight/brightness / 100) /> / sys / class" etc ... it could fix it, but I prefer to wait for a future update, because I do not want to write the script.

I'm using "xbacklight -inc 10" and "xbacklight -dec 10" for now. If you only work under X this might be a little more convenient (and could be mapped easisly to keybindings). Still hoping for a fix soon, though.

mcloaked · 2014-08-14 07:58:17

It would probably be a good idea to file a bug report upstream containing some diagnostic information for your Asus and HP machines, so that the developers are aware and have a chance to code a fix for the issue.

Last edited by mcloaked (2014-08-14 07:58:53)

iskandr · 2014-08-14 12:11:46

After doing a system update today, adjusting the backlight via Fn+f7/f8 works again for me. Can't really say which package fixed this issue, though.

ens · 2014-08-14 12:33:52

kelloco2 wrote:

at me the same way. Asus K75VJ . I can controll by e.g.
echo "3000" >> /sys/class/backlight/intel_backlight/brightness
but acpi hotkeys stopped working. (fn + f5/f6). others acpi hotkeys works good. I do not know if this is a bug. xmodmap recognizes my keys, so installing acpid and setting handlers for bash scripts about "echo $(cat /sys/class/backlight/intel_backlight/brightness - $(/sys/class/backlight/intel_backlight/brightness / 100) /> / sys / class" etc ... it could fix it, but I prefer to wait for a future update, because I do not want to write the script.

Same situation for Asus K55VM

iskandr · 2014-08-14 15:07:39

iskandr wrote:

After doing a system update today, adjusting the backlight via Fn+f7/f8 works again for me. Can't really say which package fixed this issue, though.

I'm getting too old for bleeding edge Today's kernel update to 3.16.1-1 broke it yet again. Fabulous....

mcloaked · 2014-08-14 16:32:45

iskandr wrote:

iskandr wrote:
After doing a system update today, adjusting the backlight via Fn+f7/f8 works again for me. Can't really say which package fixed this issue, though.
I'm getting too old for bleeding edge Today's kernel update to 3.16.1-1 broke it yet again. Fabulous....

My system continues to work fine with kernel 3.16.1-1 so probably best report it upstream as a new bug report?

ninian · 2014-08-14 21:16:47

I have an Asus Eee PC 1015PX and use gbacklight to set the brightness.
Previously I needed the kernel parameter 'acpi_backlight=vendor' for this to work right, but the latest updates haven't needed it.
Just tested under kernel 3.16.1-1 and it is still working without that parameter.

kelloco2 · 2014-08-15 12:33:48

@iskandr , @ens about backlight and fn keys:
keys work (I checked by xmodmap) and backlight control works, but only by:

/sys/class/backlight/intel_backlight/brightness

old scripts which used for example:

/sys/class/backlight/acpi_video0/brightness

stopped works.

I wonder if this is a BUG or new feature? Where are handlers in clean Linux / systemd responsible for action to acpi keys which controlls backlight? ( I checked and it's not acpid /etc/acpi/handler.sh - acpi keys backlight controll works without it ). (moreover,acpid is external application as well as xbacklight, gbacklight etc... It should work OOTB, without these applications and also in the console.)

to turn on old interface as before 3.16 try add

video.use_native_backlight=0

to GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub ( remember about grub-mkconfig -o /boot/grub/grub.cfg )

it turns on old interface:

ls -l /sys/class/backlight/
lrwxrwxrwx 1 root root 0 08-15 13:36 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
lrwxrwxrwx 1 root root 0 08-15 13:36 acpi_video1 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
lrwxrwxrwx 1 root root 0 08-15 13:36 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight

and everything works again as before 3.16.

http://cgit.freedesktop.org/xorg/driver … 0d681c171e
This is another BUG (also occurs to my laptop). I see that the code is ready, so wait for a fix update.

I wonder also whether and where to file a bug report (about fn keys + backlight control).

Last edited by kelloco2 (2014-08-15 12:38:16)

AnAkkk · 2014-08-15 12:52:34

kelloco2 wrote:

@iskandr , @ens about backlight and fn keys:
keys work (I checked by xmodmap) and backlight control works, but only by:
/sys/class/backlight/intel_backlight/brightness
old scripts which used for example:
/sys/class/backlight/acpi_video0/brightness
stopped works.
I wonder if this is a BUG or new feature? Where are handlers in clean Linux / systemd responsible for action to acpi keys which controlls backlight? ( I checked and it's not acpid /etc/acpi/handler.sh - acpi keys backlight controll works without it ). (moreover,acpid is external application as well as xbacklight, gbacklight etc... It should work OOTB, without these applications and also in the console.)

This is normal. There is just supposed to be one backlight interface, it was a "bug" in the first place that it registered both intel_backlight and acpi_video0. On many computers like mine acpi_video0 would just do nothing at all, which made backlights key not work as it was picked up by default.

Last edited by AnAkkk (2014-08-15 12:53:03)

kelloco2 · 2014-08-15 13:25:48

Okay, and do You know what is responsible for actions to acpi keys (which controls backlight) ? I'm thinking about clean Arch Linux without any xbacklight, gbacklight etc... maybe it's systemd-backlight.service ? It works in console too.

Arch Linux

#1 2014-07-29 18:38:53

[SOLVED] After xorg-server update backlight is not behaving

#2 2014-07-30 02:29:28

Re: [SOLVED] After xorg-server update backlight is not behaving

#3 2014-07-30 13:32:54

Re: [SOLVED] After xorg-server update backlight is not behaving

#4 2014-07-30 16:39:56

Re: [SOLVED] After xorg-server update backlight is not behaving

#5 2014-07-30 21:39:35

Re: [SOLVED] After xorg-server update backlight is not behaving

#6 2014-08-01 03:16:58

Re: [SOLVED] After xorg-server update backlight is not behaving

#7 2014-08-01 20:18:50

Re: [SOLVED] After xorg-server update backlight is not behaving

#8 2014-08-01 22:11:43

Re: [SOLVED] After xorg-server update backlight is not behaving

#9 2014-08-01 22:25:23

Re: [SOLVED] After xorg-server update backlight is not behaving

#10 2014-08-07 09:06:02

Re: [SOLVED] After xorg-server update backlight is not behaving

#11 2014-08-07 16:46:20

Re: [SOLVED] After xorg-server update backlight is not behaving

#12 2014-08-13 08:57:35

Re: [SOLVED] After xorg-server update backlight is not behaving

#13 2014-08-13 18:15:35

Re: [SOLVED] After xorg-server update backlight is not behaving

#14 2014-08-13 21:45:10

Re: [SOLVED] After xorg-server update backlight is not behaving

#15 2014-08-13 22:07:06

Re: [SOLVED] After xorg-server update backlight is not behaving

#16 2014-08-13 22:19:15

Re: [SOLVED] After xorg-server update backlight is not behaving

#17 2014-08-14 07:58:17

Re: [SOLVED] After xorg-server update backlight is not behaving

#18 2014-08-14 12:11:46

Re: [SOLVED] After xorg-server update backlight is not behaving

#19 2014-08-14 12:33:52

Re: [SOLVED] After xorg-server update backlight is not behaving

#20 2014-08-14 15:07:39

Re: [SOLVED] After xorg-server update backlight is not behaving

#21 2014-08-14 16:32:45

Re: [SOLVED] After xorg-server update backlight is not behaving

#22 2014-08-14 21:16:47

Re: [SOLVED] After xorg-server update backlight is not behaving

#23 2014-08-15 12:33:48

Re: [SOLVED] After xorg-server update backlight is not behaving

#24 2014-08-15 12:52:34

Re: [SOLVED] After xorg-server update backlight is not behaving

#25 2014-08-15 13:25:48

Re: [SOLVED] After xorg-server update backlight is not behaving

Board footer