Adjusting display brightness is very slow on several Dell laptops

Same problem here on Dell E6410 under Arch linux with linux 3.0.4 et gnome-power-manager 3.0.2.

Hi Mathieu,

Thanks for the reply.

I just guess there is a general issue with Dell systems.

There might be an issue with the kernel, or the gnome-power-manager.
The issue never happened on different OSes with lower kernel revisions like Fedora 13, 14 and Centos AND RHEL 5 and 6.
Also, Solaris 10 & 11 Express and OpenSolaris act very good.
They seem to overpassed this issue.

 Best regards.

Status changed to 'Confirmed' because the bug affects multiple users.

Same here, running Ubuntu 11.04 on a Dell XPS 17 (a.k.a. L702x) with a Nvidia GT555M (without optimus).

I have this too, with Ubuntu 11.10 on a Dell XPS 17 L702X. I'm running Bumblebee for the graphics driver.
What is *very* odd is that the brightness keys are very slow if I use the internal keyboard, but they work immediately if I use my external keyboard (a wired Apple aluminium keyboard).

I have the same problem on a E6520 with an Intel Graphics card

Also, I just thought someone should quantify *how* slow it is. I just timed it, and it takes 25 seconds for the button presses to register (for the internal keyboard, as I mentioned previously).

This bug also affects me with 12.04. I have a Dell E6520 with Intel+NVidia (optimus). I see different timings than Sparhawk

This happened both with a fresh installation, and after installing bumblebee. In both cases optimus was ON in the bios, but in the former case the system was falling back unity2D (I believe), and after installing bumblebee it uses unity3D (though always with the intel card).

The bug happens regardless on whether the nvidia card is on (i.e. while optirun glxgears is running) or off.

The bug also happens when switched to a virtual console with CTRL-ALT-F1.

When I give one quick tap of brightness up using the laptop keyboard (Fn + Arrow up), I see the following:
- 1 second delay, nothing happens
- brightness is changed 1 step up
- 0.4 seconds delay, during which at some point the brightness popup appears
- brightness is changed another step up
- 0.4 seconds delay
- brightness is changed another step up (sometimes, and sometimes one step more).

So with one tap I get at least three brightness steps.

The same happens when reducing brighness.

During the time (roughly 2 seconds) this happens, mouse is sluggish and all animations (including opengl ones) become jerky. After, everything is normal.

Top does not show any process eating CPU.

dmesg shows nothing.

Other special keys on the laptop (i.e. keyboard brighness, sleep, touchpad off, screenshot) work fine without delays.

Also, this may be related (from 2008): http://ubuntuforums.org/showthread.php?t=777947

Also of possible interest. On my system I have three devices of class "backlight":

> ls -l /sys/class/backlight/
total 0
lrwxrwxrwx 1 root root 0 Jun 12 14:17 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
lrwxrwxrwx 1 root root 0 Jun 12 13:39 acpi_video1 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
lrwxrwxrwx 1 root root 0 Jun 12 14:17 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight

Each of these devices has a file inside called "brightness". The way these files change is interesting and suggests there is a probelem/confusion/interaction among acpi_video0 and acpi_video1

I could see what happens with the following command:

 watch -d -n 0.1 "cat /sys/class/backlight/acpi_video0/brightness && cat /sys/class/backlight/acpi_video1/brightness && cat /sys/class/backlight/intel_backlight/brightness"

then watching how the values change in reaction to brightness keypresses.

The intel_backlight/brightness value stands fixed at 497

The acpi_video0/brightness and acpi_video1/brightness values are normally not the same.
e.g. the following happens:

Values are:
6 -- 7

then I do one Fn+ArrowUP keypress for increasing brighness. After 1s, values become (but brightness does not change):
8 -- 7

Then after 1s and at 0.5s intervals, they change to
8 -- 9
8 -- 10
8 -- 11

One thing it always happens is that after a single keypress of brightness up (down), the first value acpi_video0/brightness gets the value of acpi_video1/brightness plus (minus) one, respectively.

Then acpi_video1/brightness continues to change in the same direction.

Interesting find!

FWIW, on my system, intel_backlight/brightness is fixed at 4319, but acpi_video0/brightness is also fixed at 14. I could change the value of acpi_video1/brightness from 0 to 15 by altering the brightness either with the keys on my USB keyboard, or by using "$ xbacklight -set n", where n is a number (0 to 100).

For some reason the internal keyboard's brightness buttons are not working at the moment, but I've been having 3 different kinds of Unity crashes almost every day, so there's no certainty that my system is currently 100% functional!

Isn't that same as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828296

Thought I would post a confirmation a HP as well. Dv6t QE 7000 with HD4000+GT650m Optimus and Ubuntu 12.04 x64, this same issues is noticeable from a clean install all the way to installing Bumblebee. Adjusting brightness via the brightness and lock window introduces lag only momentarily and while the brightness is actually changing. Adjusting via the laptop's keyboard has prolonged (10s?) effects on the mouse cursor and delay to the on-screen display pop-up.

Okay guys, thanks for your consideration.

It looks like we're all experiencing this issue on the following hardware products running Ubuntu:
Dell E and XPS series & HP DV6t QE7000.
Looking at the list of Ubuntu's releases, it looks like 11.04 (Natty) will be EOLed soon, more exactly October 2012.

https://wiki.ubuntu.com/Releases
I'm quite sure there won't be any fix for Natty, but I hope there will be for 12.04 as this is a long term support release.

Cheers.

Svens, are you using bumblebee too?

Hi Sparhawk,

No, I'm not using bumblebee, and I don't have a nVidia grapghics card on any of the indicated Dell laptops.
Dell E5410, E5420 and E6420.

As chrmhoffmann suggested, this bug may be the same as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828296

The workaround mentioned there works on my laptop. There is still some delay (0.1s max), but almost unnoticeable!
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828296/comments/5

Thanks lale. I can confirm that this workaround also works on my laptop (Dell XPS 17 l702x).

This seems to be fixed in Quantal (12.10). I didn't configure any workaround and the brightness adjustment feels snappy after upgrading to 12.10.

Hi,

this bug seems to have reappeared, I didn't have any issue on 12.10. Since I upgraded to 13.04, the brightness adjustement is sluggish, it takes 2 seconds or more after pressing the Fn keys.

I'm not sure if it's related, but I cannot change brightness at all any more on my Dell l xps 17 l702x, since the upgrade to (k)ubuntu 13.04.

More info here https://forum.kde.org/viewtopic.php?f=63&t=110984

I haven't tested this on 13.04 yet.
I kind of prefer Centos now as it seems more stable and long-term supported,
and I'd rather have my apps running smoothly on a stable yet secure system.

On Sun, Apr 28, 2013 at 3:32 AM, Sparhawk <email address hidden> wrote:

> I'm not sure if it's related, but I cannot change brightness at all any
> more on my Dell l xps 17 l702x, since the upgrade to (k)ubuntu 13.04.
>
> More info here https://forum.kde.org/viewtopic.php?f=63&t=110984
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/847001
>
> Title:
> Adjusting display brightness is very slow on several Dell laptops
>
> Status in “gnome-power-manager” package in Ubuntu:
> Confirmed
>
> Bug description:
> Changing the brightness via FN key combination or via the brightness
> applet is very slow.
> the CPUs don't seem to go to 100%, but the adjustment process seems
> relatively slow.
> The mouse cursor is also sluggish.
> Reinstalled the OS twice, but not because of this issue and the problem
> seems to persist.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.04
> Package: gnome-power-manager 2.32.0-2ubuntu2.1
> ProcVersionSignature: Ubuntu 2.6.38-11.48-generic 2.6.38.8
> Uname: Linux 2.6.38-11-generic x86_64
> Architecture: amd64
> Date: Sun Sep 11 15:29:02 2011
> GnomeSessionIdleInhibited: No
> GnomeSessionInhibitors: None
> GnomeSessionSuspendInhibited: No
> InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64
> (20110427)
> MachineType: Dell Inc. Latitude E5410
> ProcEnviron:
> LANGUAGE=en_US:en
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-generic
> root=UUID=0dfaacc9-c19d-425b-963d-dabb87ae18bc ro quiet splash vt.handoff=7
> SourcePackage: gnome-power-manager
> UpgradeStatus: No upgrade log present (probably fresh install)
> dmi.bios.date: 01/28/2011
> dmi.bios.vendor: Dell Inc.
> dmi.bios.version: A09
> dmi.board.name: 05C67D
> dmi.board.vendor: Dell Inc.
> dmi.board.version: A00
> dmi.chassis.type: 9
> dmi.chassis.vendor: Dell Inc.
> dmi.modalias:
> dmi:bvnDellInc.:bvrA09:bd01/28/2011:svnDellInc.:pnLatitudeE5410:pvr0001:rvnDellInc.:rn05C67D:rvrA00:cvnDellInc.:ct9:cvr:
> dmi.product.name: Latitude E5410
> dmi.product.version: 0001
> dmi.sys.vendor: Dell Inc.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/847001/+subscriptions
>

--

--
-----------------------------------------------------------
Constantin Roman/ Iasi, Romania.

T:+40 754 236 958 / +40 731 394 551
W: www.svens.ro
E: <email address hidden> / <email address hidden>

Ubuntu 12.04 + fn keys on my ASUS K72D = 27 seconds delay

I see this on my HP DV6T 7000 in Ubuntu 13.04. The workaround in #17 does not work for me.

Though, interestingly, after applying the workaround, if I put the computer to sleep / standby and wake it up again, the fn keys work fine.

Same problem on HP 630 running up to date Ubuntu 12.04 64bit.
The "acpi_backlight=vendor" workaround did not solve the problem at all.

I'm experiencing this too, using Ubuntu 13.10 on Dell E6530 laptop.

After pressing Fn+up/down, nothing happens for 1-2s, then the brightness is changed, then the OSD for it pops up. I can only change the backlight in steps with this frequency.

During that waiting, the whole system (terminals, mouse, keyboard, ...) becomes sluggish, CPU meter does *not* go up.

I don't remember to change anything related since the install. The backlight stepping works find on the older Dell V13 laptop using Ubuntu 13.04 (though it had its own problems in the past -- one direction keypress behind).

same problem on Olivetti Olibook S1530

Intel HD 3000

Also occurs on my Dell Latitude E5430

Can any one else confirm that directly changing via the command line is instant ? It certainly is for me eg.

$ cat /sys/class/backlight/intel_backlight/max_brightness
976
$ cat /sys/class/backlight/intel_backlight/brightness
123
$ echo 600 | sudo tee /sys/class/backlight/intel_backlight/brightness
600
$ echo 200 | sudo tee /sys/class/backlight/intel_backlight/brightness
200

Might this be upstream kernel issue : https://bugzilla.kernel.org/show_bug.cgi?id=63931 ?

I do confirm that changing brightness via command line is instant (while the fn key combination is really slow).

I have a dell E5430 with ubuntu 13.10

It looks like the issue doesn't persist in 14.04. I've only tried this on a e6420 dell.<a href="https://overview.mail.yahoo.com?.src=iOS"><br/><br/>Sent from Yahoo Mail for iPhone</a>

I am running Ubuntu Gnome 14.04 32-bit 3.13.0-17-generic and i also have this problem.
I am on a Dell E6520.

Tom Chiverton: I can confirm that it is instantly, yes.

Not any better on 14.04 LTS beta 2

Mone's better. 14.04 beta2, dell latitude e6420. <a href="https://overview.mail.yahoo.com?.src=iOS"><br/><br/>Sent from Yahoo Mail for iPhone</a>

Mine's better, too! E6420 as well.

i suppose on my E5430 it's better, but not fixed.

Same issue on Dell Latitude E5430. Just freshly upgraded from Precise.

On Trusty:
- Using Fn+key is barely useable. Dimming by very tiny steps, and slow to react (like 10s to get OSD, 10s more to get effect).
- Using brightness settings is also slow to react (10s-ish)
- Tom Chiverton's trick works instant (i.e. echo 600 | sudo tee /sys/class/backlight/intel_backlight/brightness)

On Precise, I had some latency, but usually hammering the Fn+light key did the job just after a couple of secs.

Updated from Ubuntu 13.10 to 14.04. Keyboard input is sluggish. When typing one letter appears after I type the next one.

While changing brightness using fn + brightness key notification appears but the brightness change after a long time or does not change at all. I am using a Lenovo ThinkPad L430.

Note: I did not have any such problem with Ubuntu 13.10 or previous version in the same laptop.

Dell E7440, same problem on 14.04: very quick to change brightness using intel_backlight command, but hardward keys (Fn-Up/Down) pause the computer briefly.

Thanks to instruction from user Toz (http://ubuntuforums.org/showthread.php?t=2208278), the fix requires both "acpi_backlight=vendor" kernel param and creating the /usr/share/X11/xorg.conf.d/20-intel.conf file:
-------------------
Section "Device"
        Identifier "card0"
        Driver "intel"
        Option "Backlight" "intel_backlight"
        BusID "PCI:0:2:0"
EndSection
-------------------

My Dell Latitude E5430 only needed the kernel param adding to work correctly.

Adding the xorg.conf file as well just caused it to oscillate rapidly +/- 10% with a permanent on screen KDE brightness bar.

It seems to be fixed on my machine now :)
Dell E6520

Fixed on mine too.
Latitude E5430 on Ubuntu 14.04.1 LTS

Bug reappeared in 18.04.

Dell Precision M4800, running the standard Ubuntu Gnome shell desktop (on Xorg), Intel Graphics. No issues in 16.04 (or perhaps a tiny delay?), but unworkable in 18.04.

Both Fn-Up/Down and `echo value | sudo tee brightness` exhibit the delay (~2-3 seconds normally). Notable is that the brightness seems to change *immediately* after echoing into sysfs, so all the delay occurs in the return of the call back to the prompt.

In /sys/class/backlight I have only intel_backlight. No difference with or without Backlight option in xorg.conf, nor with the acpi_backlight=vendor kernel param.

Also notable: when performing the brightness change in a virtual terminal, it is *instantaneous*. The issue only occurs in the graphical VT running the desktop environment.

Adding some more information. Running the following as root in a gnome terminal:

   SYSFILE=/sys/class/backlight/intel_backlight/brightness
   OLD_VAL=$(cat $SYSFILE)
   NEW_VAL=$((OLD_VAL + 100))

   T0=$(date +%N)
   time echo $NEW_VAL | tee $SYSFILE
   T1=$(date +%N)

   echo "Total time (millis): $(((T1 - T0)/1000))"

Gives the following:

   real 0m0.002s
   user 0m0.002s
   sys 0m0.001s
   Total time (millis): 3502

In other words, the write to sysfs returns in 2ms (and indeed, brightness changes instantly), but it takes 3502ms for control to get back to the prompt.

During that time, the system seems to hang, but keypresses are collected: they are all echoed to the terminal right after the command returns. So the question then is: where are the 3 seconds spent?

I'm happy to experiment if someone has instructions.

Added gnome-shell to affected packages, as the issue is independent of gnome-power-manager.

Comment #46 suggests to me the delay is in writes to /sys/class/backlight/. Indeed they don't use much CPU time but take too long to return. So that would make this a kernel bug...

Status changed to 'Confirmed' because the bug affects multiple users.

Hi, I still have this issue. Using Ubuntu 18.04 on Dell XPS 9570.
Any way to get a workaround for that?

Same issue here with Ubuntu 18.04 on Dell Inspiron 15R 5521.

I have tried changing
       GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
       to
       GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor".
on /etc/default/grub and did not help.

Also tried the solution on https://ubuntuforums.org/showthread.php?t=2208278 and did not do anything.
Both brightness and volume keys are really slow do adjust and the brightness ones always freeze the screen for good 5 seconds.

Might not be related, but check if you have a high file descriptor limit configured (1048576). In my case that caused a delay in the pkexec cmd used to change the brightness. See https://forum.manjaro.org/t/very-slow-response-of-brightness-controls-in-gnome/74891/18 and https://gitlab.freedesktop.org/polkit/polkit/issues/87

Bug happens on ubuntu 19.10 on a dell 7520. Here's what the command lspci -k | grep -iA2 VGA returns:

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
 Subsystem: Dell 3rd Gen Core processor Graphics Controller
 Kernel driver in use: i915
--
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Chelsea LP [Radeon HD 7730M]
 Subsystem: Dell Chelsea LP [Radeon HD 7730M]
 Kernel driver in use: radeon