References to other reports of this issue: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/847001 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828296 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732753 When changing the backlight in the default setup on many Dell and at least some HP laptops, while the backlight does change, the X environment becomes unresponsive for several seconds per backlight change (thus changing from minimum to maximum brighness can cause X to be unresponsive for 30+ seconds). This seems to be caused by the server preferring the acpi backlight over the intel backlight. The second launchpad link has a patch and a workaround that both purport to fix this. The patch (which is 2 years old, but should still apply after adjustments for files being moved in the source tree) addresses the issue by making the intel_backlight sysfs interface be preferred over the acpi interfaces. The workaround given (which I can confirm works) is to add acpi_backlight=vendor to the kernel boot, which effectively disables the acpi backlight entries and causes the driver to pick (for me) the dell_backlight entry. From the linked reports, for others the dell backlight entry doesn't exist, so the intel backlight is picked. With the server having chosen one of the non-acpi backlight entries, brightness changes work and are nearly instantaneous.
I also tested using the intel_backlight on my system (instead of the dell_backlight), and it works properly too: Section "Device" Identifier "Intel Graphics" Driver "intel" Option "Backlight" "intel_backlight" EndSection
It's yet another bug in the ACPI firmware. It has been decided that for Windows 8 machines that the ACPI layer is so typically buggy that the kernel will not expose the advertised ACPI backlight routines. But prior to that using the ACPI layer was the only universal way to control the backlight. (I have a few machines on which the backlight is not controlled by Intel's PWM.) Suffice to say, all I can other is the workaround, the root cause is elsewhere.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.