Inspiron 1420 LCD brightness keys broken

gnome-power-manager should be listening to keypresses and adjusting the brightness accordingly. Can you (from a shell) run

killall gnome-power-manager

gnome-power-manager --no-daemon --verbose 2>/tmp/output

and then hit the brightness keys? Then ctrl+c it and attach /tmp/output and the output of lshal to this bug.

Sorry, I don't even have gnome-power-manager installed as I'm running KDE. I haven't changed my KDE setup for quite a while though, and the power manager in KDE seems to work just like it did before. I don't think it was catching keystrokes in the past, because I seem to remember the Fn+Up/Down keys working in the virtual consoles but they don't any more.

Confirming this behaviour on my Dell XPS M1710 running Kubuntu Gutsy - Fn+Up/Down work while booting (I assume they are still BIOS controlled at this point) until X and/or KDM starts. Possible duplicate/related to #140839 although symptoms are not quite identical (neither key works for me, while that bug reports that Fn+Down still works, though this may be due to differences with how KDE and Gnome handle this).
I can still alter the brightness through /proc/acpi/video/VID/LCD and dellLcdBrightness from libsmbios, and it was working fine before I upgraded earlier today.

Getting and setting the brightness through D-Bus also works fine

@Matthew Garrett:

The problem is that, when brightness max levels is more than 20, g-p-m use an increase/decrease step value of max_levels/20 (5%).
So, in my case, acpi reports brigthness max levels=100, and possible brightness values are: 12 24 36 48 60 72 84 100.

When I'm at 72, if I try to increase brightness using hotkeys, g-p-m tries to set brightness to 79, but it's not enough to get to the next brightness level. Please also read my comment at <https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/140839/comments/5>.

This has been also reported at bug #140839.

Oops, sorry, it's not the same bug. Please ignore my last comment.

But, when killing gnome-power-manager, I also experience this bug, that is, I can't change my laptop brightness by using hotkeys but hotkeys are supposed to change brightness by hardware.

I don't think this is a bug in kpowersave, since I don't have it installed and never have. The closest thing I have to that is kde-guidance-powermanager (and I do have kubuntu-desktop and its dependencies installed).

Has there been a recent change in the way these brightness keys are handled, so that they are caught and no longer handled by the BIOS?

kpowersave has nothing to do with this bug. I experience this bug using gnome when gnome-power-manager is not loaded.
I think it's probably related to the acpi video module.

While I booted up I continually hit Fn+Up/Down until the point when they stopped working. Noting the messages on screen at the time I then booted into recovery mode and manually started S10acpid and bingo the keys stopped working.

And specifically occurs the moment that /lib/modules/2.6.22-11-generic/kernel/drivers/acpi/video.ko is loaded

And so my _workaround_ is as follows:

# echo blacklist video >> /etc/modprobe.d/
# reboot

Ahh that should have been:

$ sudo echo blacklist video >> /etc/modprobe.d/blacklist
$ sudo reboot

Backlight handling has to be handled by userspace. I'm punting this over to the general KDE task, because I'm honestly not sure which part of KDE should be taking responsibility for this.

I think that's correct for laptops with keys that only send a keypress event, but there're laptops who change brightness by hardware (probably by sending some signal to the BIOS).
It's not desktop environment specific, since I can change brightness with hotkeys in grub menu, but not after the acpi video module is loaded.
Probably, when gnome-power-manager (or its kde counterpart) is loaded, it gets the keypress and change brightness, but I don't see why shouldn't I be able to change brightness when g-p-m is not loaded, since I can do it when no OS is loaded.

My thinking is that on these models we should just let the BIOS handle
this, since it handles it very well, and doing it through userspace
means:
* We need to handle it in every environment - KDE, Gnome, pure
console, X with no window manager, etc.
* We need to make sure it's always responsive and users do not
perceive any delay
* We're essentially going to end up telling the BIOS to do exactly
what it wanted to do in the first place since these models handle it
through libsmbios (I believe the controls in ACPI use libsmbios anyway
based on what I read in a pre-feisty bug report).

The only reason I can think of for not trusting it to the BIOS is if
we need to override it for some reason (software driven brightness
profiles? BIOS already keeps them for battery vs. AC, and it should
still be possible to do more sophisticated stuff without disabling
this feature since we can still get&set the brightness at any time).

Just my 2c. Maybe there is a very good reason for not trusting the
BIOS that I'm not seeing (Aside from "because we can").

Agree with above.

Before the update that broke my Fn brightness keys, software-driven brightness did work. kde-guidance-powermanager has a slider bar that controls brightness when connected to AC/battery, and those worked fine (and still do). I could also control brightness with the keyboard though, which I can't do now.

After booting in recovery mode, I can use hotkeys to change brightness.
After doing "modprobe video", brightness hotkeys stop working. The only new module reported by lsmod is video.
After doing "rmmod video", lsmod doesn't show the video module anymore, and modules shown are exactly the same as after a recovery mode boot, but brightness hotkeys still don't work.
There's nothing new in log files.

Can someone give some hint on what's going on after loading the acpi video module that persists after unloading it?

I have a Dell XPS M1210.

My LCD brightness can go down, but the keys can't bring it back up. If I start up the power management, I can use the slider to adjust the brightness.

Here's the output of gnome-power-manager when trying to adjust the brightness.

As stated in <https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/121833/comments/11>, you can control brightness using hotkeys by adding 'options video no_automatic_changes=0' to some file in /etc/modprobe.d/ and reloading the video module.

I don't know why that change was made, but I think that's what this bug is about, and not some kde package.

The FN-up/down hotkeys for increasing and decreasing brightness won't work in Gutsy Beta for me. I also had this bug in a development version of Feisty and then it could be fixed by adding "blacklist video" to /etc/modprobe.d/blacklist. When the final was out, I didn't need to blacklist the video-module anymore. Now in Gutsy, since Tribe5 the FN-keys wont work anymore. I have all updates installed, even the Gutsy Beta livecd doesn't work with the FN-keys for brightness.
DarkStarSword suggested the same solution again, to blacklist the video-module and it worked for me. I noticed that I can't change the brightness from the guidance-power-manager applet anymore since the video-module isn'nt loaded.

It seems clear to me that this is some kind of regression in the video-module?

Confirm behavior on Dell Inspiron 6400 with Kubuntu Gutsy installed (2.6.22-14-generic (#1 SMP Wed Oct 10 06:00:47 GMT 2007))
Never had it in Feisty or Edgy.

The brightness keys in my vostro 1000 and Ubuntu 7.10 are completely dead. Before upgrading they keys behaviour was vey weird.

I still don't know where is the problem, and I don't have any solution.

I just can change the brightness manually using (*without* blacklisting video module). At least is a temporary solution to me:

First, view all the possible levels in LCD brightness file:

cat /proc/acpi/video/VGA/LCD/brightness

choose one, say X level (for example 75), and
echo 75 | sudo dd of=/proc/acpi/video/VGA/LCD/brightness

Adding the option 'no_automatic_changes=0' doesn't works completely for me. It just let me push the brightness down (Fn+UP doesn't works) and only using a pure terminal (i.e. CTRL+ALT+F1).

The "brightness miniapplication" (I don't know the exact name in english) doesn't works. The gnome-power-manager doesn't shows me any option to adjust the brightness.

BIOS: 2.6.1

Is this still an issue in Intrepid?

The Fn+Up/Down key has been working on and off throughout the updates over the last year, but at the moment it is working for me and has been since at least Intrepid Alpha 5.

Fixed in Intrepid for me. Marking bug as solved.

Glad to see this isn't an issue any more.
For future reference, the status "Fix released" is used to mark bugs as fixed.