Brightness key stopped working after update [Gutsy]

[Mikael Gerdin]

I'm running Kubuntu Gutsy (and have been since gutsy was a few weeks old)
After some upgrade in the last two weeks (sorry, I don't have an exact version or date).
The LCD brightness keys on my Dell XPS m1210 laptop has stopped working.
I've tried disabling auto-start of hotkey-setup, but it doesn't help.
If i start in single-user mode then the keys do work.
When monitoring the output of acpid and pressing the keys I see that it's calling the
/etc/acpi/video_brightness{up,down}.sh scripts but nothing happens.
I can also see that hal can recognizes the keys by running 'lshal -m' and pressing them.
The only way I can set the brightness now is with the GUI-based guidance-power-manager.

[Thomas Sommer (flightsupport)]

Same problem here with Ubuntu Gutsy on a Dell Inspiron 640m/E1405.
Brightness-down works, Brightness-up does not.

[Francisco Borges (francisco-borges)]

Running Dell Inspiron 6400 here.

# dmidecode -s system-manufacturer
Dell Inc.
# dmidecode -s system-product-name
MM061
# dmidecode -s system-version
Not Specified

Just updated to Gutsy BETA, and brightness keys don't work anymore.

If I remove the power cable, brightness goes down, but if I plug it back, brightness first comes back, but after a few seconds it goes down again.

I can also see at /var/log/acpid that the script is being called, but it simply does not work. This is the log entry I get from trying to increase the brightness:

[Sat Sep 29 14:10:31 2007] notifying client 5474[0:0]
[Sat Sep 29 14:10:31 2007] executing action "/etc/acpi/video_brightnessup.sh"
[Sat Sep 29 14:10:31 2007] BEGIN HANDLER MESSAGES
[Sat Sep 29 14:10:31 2007] END HANDLER MESSAGES
[Sat Sep 29 14:10:31 2007] action exited with status 0
[Sat Sep 29 14:10:31 2007] completed event "video LCD 00000086 00000000"

[der_vegi (m-may)]

I don't think this bug is related to kdebase, as it also happens on my ubuntu daily-live 20070929 (amd64). I'm using a Dell Inspiron 1501. But changing display brightness with the Fn-keys hasn't worked for me since feisty.

[Kyle S (pissboy)]

I have the same symptoms as the OP on my up-to-date ThinkPad T60 running Kubuntu. Brightness keys do not work even though "lshal -m", "acpi_listen", and acpid all see them/do the right thing. No OSD from kmilo anymore either, for anything, even volume or thinklight which work (probably only because they are done in hardware). This all worked several weeks ago, and has actually always worked up until then. Guidance can still adjust the brightness with the slider.

Although it's not related directly to this bug, I tend to think it's not coincidental that my lock (Fn-F2, used to lock the session I think, I didn't use it much), battery (Fn-F3, which used to cause guidance-power-manager to show it's tooltip), suspend (Fn-F4), and suspend-to-disk keys (Fn-F12) do not work right anymore either, and broke at the same time. Their implementations in /etc/acpi and so forth are also all similar, only generating various fake keys (see below).

The biggest problem with my troubleshooting is that I can't understand/find information on the big picture, how is this mechanism supposed to work at all to begin with. I seem to remember (although admittedly not infallibly) that the scripts in /etc/acpi used to actually modify the brightness (and perform the other key actions) directly thru /sys or /proc somehow. Now all they appear do is synthesize keystrokes using acpi_fakekey. This works right too, xev for example sees these fake keystrokes (although many of them do not have keysyms). But, is some program supposed to receive these keystrokes and perform the action? Or am I barking up the wrong tree? What is HAL's role, if any, in making this work?

After the fake key generation, I lose the trail. Any clues? This is a terrible nuisance because I use(d) these keys frequently. Being night-blinded by your laptop is not cool :)

[Thomas Sommer (flightsupport)]

Some package have been updated.
Now the FN-brightness keys work again.

- hal (0.5.9.1-6ubuntu1)
- gnome-power-manager (2.20.0-0ubuntu3)

[Kyle S (pissboy)]

On Tuesday 02 October 2007 18:26:28 Thomas Sommer wrote:
> Some package have been updated.
> Now the FN-brightness keys work again.

Still not working for me in KDE land, upgraded a number of packages, last
upgrade was less than an hour ago. Browsing the code in
guidance-power-manager right now, there was a python indentation error in
it's DCOP interface code for brightness control. Fixing that didn't make the
buttons work, however, and I can't see anywhere else besides that and the
slider controls where brightness calls to HAL are made.

So, still trying to figure it out..

[der_vegi (m-may)]

Well, for me the brightness keys still don't work in daily-live 20071003 (amd64), newest updates installed, which means that I do have hal 0.5.9.1-6ubuntu1 gnome-power-manager 2.20.0-0ubuntu3 installed.

[der_vegi (m-may)]

Maybe an output of 'lspci -vvnn' helps?

[Kyle S (pissboy)]

> ** Changed in: kdebase (Ubuntu)
> Status: New => Invalid
>
> ** Changed in: gnome-power-manager (Ubuntu)
> Status: New => Fix Released

I'd like to gently point out that the original reporter of this bug is a KDE
user. This makes no sense at all.

[der_vegi (m-may)]

Yeah, but the original reporter marked bug #105512 found on a gnome setup as a duplicate of his kdebase-bug. I kind of doubt that it is related to kde or gnome, but some different package, both have in common. Which one, I don't know.

[Francisco Borges (francisco-borges)]

On 10/5/07, der_vegi <email address hidden> wrote:
> Yeah, but the original reporter marked bug #105512 found on a gnome
> setup as a duplicate of his kdebase-bug. I kind of doubt that it is
> related to kde or gnome, but some different package, both have in
> common. Which one, I don't know.

I don't think this is a Gnome or KDE bug. Since, at least while
running KDE, the correct calls were being made (executing action
"/etc/acpi/video_brightnessup.sh").

Nevertheless, I think it is *very* counter-productive to un-mark a bug
report on kde-base and then remark it as gnome-power-manager. This is
wrong.

There are multiple reports that it is failing on kde-base, so based on
which fact this now ONLY applies to gnome-power-manager? Based on what
fact was this bug marked as "invalid" in kde-base?

One must either:
1. change this to a bug on HAL;
2. leave this as a gnome-power-manager, and kde-base bug;
3. or unmark the other bug as duplicate of this one.

FWIW I'm at work right now, so only tonight I'll be able to test if
the bug is still present in KDE or not.

Kind regards
--
Francisco

[der_vegi (m-may)]

Yes, you're right, the marking is counter-productive. It was done by too many people: One marked a gnome bug as a duplicate of a kdebase-bug, then I added gnome-power-manager, then it was marked as invalid for kde and 'fix released' for gnome by someone else, then I reopened it for gnome-power-manager, as the fix didn't work.

It might be a HAL bug, but as I am not too much into that stuff, I'll keep my fingers off marking now. ;)

[Mikael Gerdin (mgerdin)]

If it's not a HAL bug, then IMHO it should be made a HAL bug, because I want to be able to set the brightness of my laptop screen without having to start KDE or Gnome in order to do so.

[Kyle S (pissboy)]

On Friday 05 October 2007 11:22:41 der_vegi wrote:
> Yes, you're right, the marking is counter-productive.
> [...]
> It might be a HAL bug, but as I am not too much into that stuff, I'll
> keep my fingers off marking now. ;)

Yeah it seems like we're having to speculate where the problem actually lies
because I for one still cannot find any documentation or insight on how it's
*supposed* to work.

It looks to me like they moved most of the ACPI event-handling functionality
out of the /etc/acpi scripts and into gnome-power-manager,
guidance-power-manager, or kpowersave which listen for the events via HAL. If
that is the case, then neither guidance nor kpowersave seem have any
provision at all for handling brightness key events in the first place, so
perhaps the modifications to /etc/acpi should be reverted for the brightness
keys.

On the other hand, this could be dead wrong, in which case, somebody who knows
how these subsystems are set up in (k)ubuntu, and/or where to find said
information, *please* chime in.

And I tend to agree that having to be logged into your DE to change the screen
brightness using dedicated hardware keys is... not ideal.

[der_vegi (m-may)]

Hm. Maybe it has to to something with the display drivers? Because there is a tool called 'radeontool' which claims to be a 'utility to control backlight on radeon based laptops'. I can turn the backlight completely off with that tool, but cannot dim it. Dimming for me only works with 'echo -n 62 > /proc/acpi/video/VGA/LCD/brightness'.

Do you all have ATI Radeon cards? I have an ' ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP]'.

[Francisco Borges (francisco-borges)]

This is weird.

(Running Dell Inspiron 6400 with Intel 945GM graphics card)

When logging in with KDE (this is important) If I listen to "acpi_listen" or "lshal -m" everything seems to be working... except for the actual brightness which does NOT change. I have these processes running:

 ~ % ps axf | grep hal
 5043 ? Ss 0:00 /usr/sbin/hald
 5044 ? S 0:00 \_ hald-runner
 5114 ? S 0:00 \_ hald-addon-keyboard: listening on /dev/input/event1
 5117 ? S 0:00 \_ /usr/lib/hal/hald-addon-cpufreq
 5118 ? S 0:00 \_ hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
 5119 ? S 0:00 \_ hald-addon-keyboard: listening on /dev/input/event4
 5120 ? S 0:00 \_ hald-addon-keyboard: listening on /dev/input/event5
 5121 ? S 0:00 \_ hald-addon-keyboard: listening on /dev/input/event6
 5187 ? S 0:00 \_ hald-addon-storage: polling /dev/scd0 (every 2 sec)
 7630 pts/2 S+ 0:00 | \_ grep --ignore-case --color=auto --extended-regexp hal
 6361 pts/4 S+ 0:00 \_ lshal -m

If I start a new session with GNOME. The very same acpi/HAL events are generated, and now they do work; and what is worse, if I return to my (still open) KDE session, now the brightness keys also DO work. However I don't have any difference in the ACPI/HAL logs nor in the HAL processes running.

Can anybody how can I track this further?

Kind regards

[der_vegi (m-may)]

This reminds me of some curiosity I experienced in Feisty: Executing the command 'echo -n 62 > /proc/acpi/video/VGA/LCD/brightness' didn't instantly change the brightness, only if I pressed 'Fn + down (or maybe up)' the brightness was set to the given value. But still, using only the Fn-key without the command didn't work.
I can't reproduce this on Gutsy, though.

[Alexander Hunziker (alex-hunziker)]

As of today, brightness setting fully works for me on a T60. Anyone confirming that?

[Kyle S (pissboy)]

On Saturday 06 October 2007 15:18:01 Alexander Hunziker wrote:
> As of today, brightness setting fully works for me on a T60. Anyone
> confirming that?

Also on a T60 here, still not working for me (in KDE).

[Francisco Borges (francisco-borges)]

On 10/7/07, Kyle S <email address hidden> wrote:
> On Saturday 06 October 2007 15:18:01 Alexander Hunziker wrote:
> > As of today, brightness setting fully works for me on a T60. Anyone
> > confirming that?
>
> Also on a T60 here, still not working for me (in KDE).

I'm on a Dell Inspiron 6400.

The brightness keys work on Gnome, but not on KDE :-(

[der_vegi (m-may)]

Still not working on Gnome for me, all updates until now (Oct. 13th) installed... Dell Inspiron 1501.

[racoon97 (racoon97)]

Dont't work for me too, Dell Inspiron 1501.

[der_vegi (m-may)]

Maybe that information helps: When I try to use the gnome-brightness-applet, it refuses to work, telling me, that the brightness of my screen couldn't be detected.

[Thiago Teixeira (tvst)]

i'm having the same problem on a thinkpad t60.

just so you know, this bug [url=http://bugzilla.gnome.org/show_bug.cgi?id=469748]has been reported upstream[/url]. [url=http://bugzilla.gnome.org/show_bug.cgi?id=469748#c17]it appears[/url] that the hal guys switched the type or the brightness variable from uint to int to uint again, and probably confused the gnome power management guys.

hopefully someone will fix this soon.

[Thiago Teixeira (tvst)]

Ok, i'm reposting this to try and fix the urls from the previous post. (I couldn't find any documentation on whether i should use bbcode or html or what)

i'm having the same problem on a thinkpad t60.

just so you know, this bug <a href="http://bugzilla.gnome.org/show_bug.cgi?id=469748">has been reported upstream</a>. <a href="http://bugzilla.gnome.org/show_bug.cgi?id=469748#c17">it appears</a> that the hal guys switched the type or the brightness variable from uint to int to uint again, and probably confused the gnome power management guys.

hopefully someone will fix this soon.

[Loic Nageleisen (lloeki)]

I'm encountering this problem on my asus w7j too.

Basically:
- pressing keys gives acpi event (checked wich acpi_listen), which in turn generates fake keypress events (checked with xev) and hal events (checked by hal -m)
- pressing keys does change brightness in gnome. 'cat /proc/acpi/video/VGA/LCDD/brightness' value does not change. 'cat /proc/acpi/asus/brn' value changes.
- pressing keys does not change brightness in KDE or on console, 'cat /proc/acpi/video/VGA/LCDD/brightness' does not change. 'cat /proc/acpi/asus/brn' value does not change.
- changing brightness settings in KDE power management settings works, and 'cat /proc/acpi/video/VGA/LCDD/brightness' does not change. 'cat /proc/acpi/asus/brn' value changes.

my conclusion:
- acpi stuff now only generates events and does not takes action anymore
- gnome power manager is the only app currently able to catch these key or hal events and change brightness accordingly
- there's no app for KDE able to do that
- there's no console app either

so one should:
1. implement this in kde power manager
2. implement this in a daemon listening for hal events (so that it works in console mode)
3. make sure those cooperate so that brightness is not set multiple times for one keypress

note: bugs above regarding gnome-power-manager working and then not were unrelated to this one and fixed (see tvst comment).

[Francisco Borges (francisco-borges)]

Running KDE on Dell Inspiron here.

Using KDE power manager does work.

From the console, with KDE running, I can change the brightness settings using:

% dcop power-manager-6385 power-manager brightnessUp

% dcop power-manager-6385 power-manager brightnessDown

(Use "% dcop power-manager-6385 power-manager" to see all the options).

[...]

However, the brightness keys don't work. What the brightness keys do
is to execute /etc/acpi/video_brightnessdown.sh and
/etc/acpi/video_brightnessup.sh. (Anyone wanting to check this should
use xev and 'lshal -m')

These scripts only call "/usr/bin/acpi_fakekey" with the correct key number.

So the problem seems to be on the "acpi-support" package.

kind regards,
--
Francisco

[Kyle S (pissboy)]

Loic Nageleisen wrote:
> my conclusion:
> - acpi stuff now only generates events and does not takes action anymore
> - gnome power manager is the only app currently able to catch these key or hal events and change brightness accordingly
> - there's no app for KDE able to do that
> - there's no console app either

I agree with this, I posted a similar analysis a month or so ago. In
fact, as of a couple of days ago I began working around the problem in
KDE by shutting down guidance-power-manager and running gnome-power-manager.

If these analyses are correct, then I'm at a loss as to how it seems to
be overlooked that Kubuntu appears to have no facility for handling
brightness key events, and how the actual brightness-changing
functionality got removed from /etc/acpi/events before
guidance-power-manager (or whatever) grew a replacement for it.

> so one should:
> 1. implement this in kde power manager
> 2. implement this in a daemon listening for hal events (so that it works in console mode)
> 3. make sure those cooperate so that brightness is not set multiple times for one keypress

Agreed, I'd like to repeat my opinion that having to be logged into your
desktop environment to change the brightness of your LCD using
*dedicated hardware keys* is less than ideal.

[der_vegi (m-may)]

Okay, as the kde bug and the gnome bug seem to be different, I unmark Bug #105512 as duplicate as it is upstream, but still present in Gutsy as of today.

[VictorArguelles (v-arguelles)]

Same problem with a 1501. Gutsy with all the updates (it's updating some stuff right now, but they're unrelated). The funny thing is, I used to have this problem in Feisty, until Dell released a bios update. Then it _sort of_ worked. If I hit the brightness keys a few times (no matter which one), eventually it would dim a little, and if I hit them some more, it would brighten back up. I had only those two options: kind of dim, and bright, but it was better than nothing.

After I installed Gutsy (clean install), the brightness keys aren't working anymore.

I did what Francisco suggested, and all I get is a little message next to the battery icon on the system tray (is that the guidance manager?) saying: " Brightness: 0%", no matter if I say brightnessUp or brightnessDown.

[dragon76 (tfishwall)]

Kubuntu Gutsy 7.10 amd64 generic kernel.

Same problem in kde here. I have an Everex StepNote ST5340T, it is identical to an Averatec 2370 and the Averatec's are experiencing the same problem. Key presses register correctly as above posts indicate. The turn backlight off key works, but is a hardware control on this laptop, so would not be effected by this bug. I can confirm that running gnome-powermanager in place of kpowermanager allows brightness up/down keys to function properly.

[mostro (javierguajardo)]

i have same problem here i use Xfce , Fn keys for bright does not work. i have a dell vostro 1400.
it doesnt work since kernel 2.6.22-10, now im with 2.6.22-14.
When i boot old kernel fn keys work without problems.

[Mikael Gerdin (mgerdin)]

It would be nice if someone could tell me where to find an earlier kernel so I could test this on my computer as well.
Then we could dig through the kernel changelog and see what made it stop working.

[dragon76 (tfishwall)]

I can confirm that the bug is also present in kpowersave in addition to kpowermanager.

[mikelopez (e-mikelopez)]

Hi I'm running Kubuntu Gutsy on a Gateway ML6720 laptop and it doesn't work either. Based on the comments here, I decided to write a short bash script as a temporary workaround. It looks like that acpi_fakekey is not working properly. I did however notice that echoing a value to /proc/acpi/video/VGA/LCD/brightness does change the brightness of my LCD.

Not sure if this is the place to upload workarounds so I'm sorry if I'm making a mistake here. Just hoping to help those who wants to get it done without having to wait for the next upgrade.

The attached bash script works with the following syntax (run as root):
Increase brightness: lcdbryt.sh up
Decrease brightness: lcdbryt.sh dn

I placed the script in /usr/bin then edited /etc/acpi/video_brightnessup.sh and video_brightnessdown.sh to call the script I wrote.

my video_brightnessup.sh now looks:
#!/bin/bash
. /usr/share/acpi-support/key-constants
#acpi_fakekey $KEY_BRIGHTNESSUP
lcdbryt.sh up

and my video_brightnessdown.sh now looks:
#!/bin/bash
. /usr/share/acpi-support/key-constants
#acpi_fakekey $KEY_BRIGHTNESSDOWN
lcdbryt.sh dn

[Marc Carson (baggageclaim)]

mikelopez: Thanks for the script. I got it working, but I had to change "/proc/acpi/video/VGA/LCD/brightness" to "/proc/acpi/video/VID/LCD/brightness" - changing "VGA" to "VID" made it work on my Dell Inspiron E1505. Hope your fix can shed some light on the bug.

[Luka Renko (lure)]

Can each of reporters that have problem on Kubuntu Gutsy report back the following info for their laptop:

1. Exact HW
cat /var/lib/acpi-support/system-product-name

2. Does these two command (if run from Konsole) change brightness properly on your laptop?

dcop `dcop | grep power-manager` power-manager brightnessUp

dcop `dcop | grep power-manager` power-manager brightnessDown

3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
https://wiki.ubuntu.com/KubuntuLaptopKeycodes page? If not, what does it report and what does "lshal -m" report when key is pressed?

[Mikael Gerdin (mgerdin)]

* Model: Dell XPS m1210
1. system-product-name is MXC062
2. The dcop-commands work.
3. The keycodes returned are 212 and 101.

lshal -m reports
platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

A note to people who have used mikelopez's shell-script:
It somehow suppressed the output in xev when pressing brightness-down, when I removed it from /etc/acpi/video_brightnessdown.sh I could read the keycode.

[Revenant (hasana)]

1. Exact HW
 cat /var/lib/acpi-support/system-product-name

HP Pavilion dv6000 (GF651EA#ABD)

2. Does these two command (if run from Konsole) change brightness properly on your laptop?
dcop `dcop | grep power-manager` power-manager brightnessUp
dcop `dcop | grep power-manager` power-manager brightnessDown

Yes they do work.

3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
 https://wiki.ubuntu.com/KubuntuLaptopKeycodes page? If not, what does it report and what does "lshal -m" report when key is pressed?

Yes, it does and "lshal -m" reports the following :
Start monitoring devicelist:
-------------------------------------------------
22:17:45.437: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
22:17:46.116: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up

I hope it will help in resolving this issue.

[dragon76 (tfishwall)]

1. Everex StepNote ST5340T

2. The dcop commands work

3. brightness up = 212
    brightness down = 101

Just in case it helps: lsmod -m
    platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
    platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

[Kyle S (pissboy)]

> 1. Exact HW

ThinkPad T60

> cat /var/lib/acpi-support/system-product-name

2007C3U

> 2. Does these two command (if run from Konsole) change brightness
> properly on your laptop?

Yes, they do. I get a tooltip over guidance-power-manager's kicker icon
about the brightness as well, instead of the KMilo OSD that it used to
display the last time it worked.

> 3. Does your laptop return same keycodes from brightness up (212) and down (101)

Affirmative

> .. what does "lshal -m" report when key is pressed?

18:17:49.465: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = brightness-up
18:17:49.848: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = brightness-down

HTH!

[Marc Carson (baggageclaim)]

1. MM061
2. Works fine - same as Kyle S.
3. Don't see my laptop there. But here's the lshal -m output:

15:50:44.872: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
15:50:44.901: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
15:50:45.527: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
15:50:45.561: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

[Luka Renko (lure)]

Thank you all for fast response.

I have uploaded the fix to my PPA and will ask for testers (as I do not have the HW to properly test the fix) later when packages get built. Then we will see if we can request StableReleaseUpdate for gutsy.

[Luka Renko (lure)]

OK, I have test binaries for kdebase-bin and kmilo prepared in my PPA. If you would like to test it, add this to your /etc/apt/sources.list :

deb http://ppa.launchpad.net/lure/ubuntu gutsy main

Then run apt-get update and upgrade.

Then you need to logout/login (or restart the system) to test. Please report back if this works for you.

[Revenant (hasana)]

On Fri Nov 2 2007 09:15:20 Luka Renko wrote:
> OK, I have test binaries for kdebase-bin and kmilo prepared in my PPA.
> If you would like to test it, add this to your /etc/apt/sources.list :
>
> deb http://ppa.launchpad.net/lure/ubuntu gutsy main
>
> Then run apt-get update and upgrade.
>
> Then you need to logout/login (or restart the system) to test. Please
> report back if this works for you.

No, the fix is not working for me.

[Mikael Gerdin (mgerdin)]

The fix isn't working for me either, but it seems that with the package versions in http://ppa.launchpad.net/lure/ubuntu, keycodes 212 and 101 has been bound to keysyms XF86LaunchD and XF86LaunchE.

[Martin Böhm (martin.bohm)]

It doesn't work here either (MacBook).

[Luka Renko (lure)]

Interesting: for some strange reason, Launch[DE] does not work always. Have uploaded changed binaries with assign Launnch[1-2] instead - hope this helps.

[Martin Böhm (martin.bohm)]

KeyRelease event, serial 32, synthetic NO, window 0x1c00001,
    root 0x59, subw 0x0, time 77599873, (95,53), root:(99,76),
    state 0x0, keycode 101 (keysym 0x1008ff42, XF86Launch2), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Unfortunately, it still doesn't change anything.

[Revenant (hasana)]

On Sat Nov 3 2007 07:29:37 Luka Renko wrote:
> Interesting: for some strange reason, Launch[DE] does not work always.
> Have uploaded changed binaries with assign Launnch[1-2] instead - hope
> this helps.

Still nothing changed here either.

[Rodrigo (rowdrigo)]

I upgraded ny system using deb http://ppa.launchpad.net/lure/ubuntu gutsy main but doesnt work yet.
My fn-brightness still doing nothing.

[Revenant (hasana)]

I've compiled a custom kernel ( 2.6.24rc1 with git12 patch). Oddly enough the
brightness keys are working now with lure's packages.

Maybe it is a kernel issue not kde.

[VictorArguelles (v-arguelles)]

1. Inspiron 1501
2. No and no. I do get a little notification thing next to the battery icon
in the system tray. It says "Brightness: 0%".
3. Yes. Up is 212 and Down is 101.

lshal -m output:
09:41:07.799: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = brightness-up
09:41:08.377: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = brightness-down

Sorry for the late response. Everybody was reporting the dcop command to
work, but it didn't in mine. Maybe this will help.
--
//victor
http://www.perroscongatos.com/

[Francisco Borges (francisco-borges)]

> 1. Exact HW
> cat /var/lib/acpi-support/system-product-name

MM061

(it's a Dell Inspiron 6400)

> 2. Does these two command (if run from Konsole) change brightness
> properly on your laptop?

DCOP commands do work perfectly.

> 3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on

Laptop does return the correct key codes.

NOTES:

a. I still have the *Feisty* kernel installed, and everything works
fine if I boot with it.

b. Using Gutsy's highest versioned kernel, I can change the brightness
using the PowerManager (from the battery icon in the panel), but the
brightness keys do /not/ work.

c. Installed your test binaries from
http://ppa.launchpad.net/lure/ubuntu, brightness keys still don't work
after a reboot.

HTH, and thanks a lot for looking into this problem
--
Francisco

[VictorArguelles (v-arguelles)]

Just to report that the binaries from lure's ppa didn't work, but Mike
Lopez's script works on my Inspiron 1501 without a problem (I am using the
script manually, like 'lcdbryt.sh up'.

--
//victor
http://www.perroscongatos.com/

[Tim Aretz (tim-aretz)]

Just want to confirm the bug, T60.
It used to work flawlessly in Kubuntu Feisty, but not anymore since Gutsy.
The strange this is that everything looks normal (see below), it just doesnt work.
No idea where to look for the problem.

>Can each of reporters that have problem on Kubuntu Gutsy report back the following info for their laptop:
>1. Exact HW

Thinkpad T60 2007VCE

>2. Does these two command (if run from Konsole) change brightness properly on your laptop?
yes.

>3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
 >https://wiki.ubuntu.com/KubuntuLaptopKeycodes page? If not, what does it report and what does "lshal -m" report when key is pressed?
Yes,
212 NoSymbol
102 NoSymbol
lshal:
12:04:44.849: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
12:04:46.936: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

[Tim Aretz (tim-aretz)]

Update:

I just tried to activate AIGLX and Compiz and now the dcop calls don't work anymore either.
I still get an OSD-message that the brightness would change, but it doesn't.

[dresnu (dresnu)]

Same problem here on a Toshiba Satellite a100-912 running Kubuntu Gutsy.
Fn brightness keys worked in Feisty.

1. Exact HW
 SATELLITE A100

2. Does these two command (if run from Konsole) change brightness properly on your laptop?
 Yes. they step up and down of a 10% and they even show a "brightness XX%" popup window. (Even though I noticed that at 60% screen is brighter than at 70% and 80% (which don't differ) and steps from 0% to 40% have exactly the same level of brightness.

3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
 https://wiki.ubuntu.com/KubuntuLaptopKeycodes page?
Toshiba is not reported on that page but I get those keycodes (212-101) if I run xev

[Andi (andithese)]

Hi,

just to confirm for DELL Latitude D520 after upgrade Feisty -> Gutsy:

Using Feisty setting brightness worked fine without any problem!
Using Gutsy setting brightness using power manager (also kpowersave) works fine, but NOT using Fn-keys.

1. Exact HW
cat /var/lib/acpi-support/system-product-name

Latitude D520

2. Does these two command (if run from Konsole) change brightness properly on your laptop?

dcop `dcop | grep power-manager` power-manager brightnessUp

dcop `dcop | grep power-manager` power-manager brightnessDown

yes

3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
https://wiki.ubuntu.com/KubuntuLaptopKeycodes page? If not, what does it report and what does "lshal -m" report when key is pressed?

19:34:08.983: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
19:34:09.413: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

I can also confirm working Fn-keys up and down using the old kernel version 2.6.20-16-generic!!

Many thanks for your efforts!!!

[Amit Shah (am1tshah)]

I use kubuntu from gutsy. The brightness keys used to work on feisty, and stopped after an upgrade yesterday.

$ cat /var/lib/acpi-support/system-product-name
8743CTO

The dcop scripts don't work for me

$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
00:26:54.354: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
00:26:56.291: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

By echo'ing values to /proc/acpi/video/VID/LCD0/brightness I can adjust the brightness.

[psartini (piero-sartini)]

>Can each of reporters that have problem on Kubuntu Gutsy report back the following info for their laptop:
>1. Exact HW
> cat /var/lib/acpi-support/system-product-name

(ThinkPad T60p) 2007FHG

>2. Does these two command (if run from Konsole) change brightness properly on your laptop?
>dcop `dcop | grep power-manager` power-manager brightnessUp
>dcop `dcop | grep power-manager` power-manager brightnessDown

no, because:
ERROR: Couldn't attach to DCOP server!

However, brightness can be adjusted by power-manager and with
echo 10 > /proc/acpi/video/VID1/LCD0/brightness

>3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
> https://wiki.ubuntu.com/KubuntuLaptopKeycodes page?

yes

[ThomasN (tnetter)]

1. Exact HW
cat /var/lib/acpi-support/system-product-name
Answer:
HP Compaq 2510p Notebook PC

2. Do these two commands (if run from Konsole) change brightness properly on your laptop?

dcop `dcop | grep power-manager` power-manager brightnessUp
dcop `dcop | grep power-manager` power-manager brightnessDown
Answer: No. Here's the output:
object 'brightnessUp' in application 'power-manager' not accessible
object 'brightnessDown' in application 'power-manager' not accessible

3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
https://wiki.ubuntu.com/KubuntuLaptopKeycodes page?

Answer: Here's the output of lshal -m
Start monitoring devicelist:
-------------------------------------------------
16:54:21.186: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
16:54:24.172: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up

Note: Brightness buttons and Resume after Suspend work fine in Ubuntu7.10 + Gnome.
They do not work with Ubuntu7.10 + KDE nor Kubuntu 7.10.

[Luka Renko (lure)]

I have started a thread in kubuntu-devel mailing list for further debugging. If you want to participate, join the discussion there:
https://lists.ubuntu.com/archives/kubuntu-devel/2007-December/002058.html

I will also report any progress in the bug.

[Rodrigo (rowdrigo)]

In message at https://lists.ubuntu.com/archives/kubuntu-devel/2007-December/002059.html you ask results of procedure below. Don't work here.

"How to manually test this with brightness keys on your laptop:

1. Manually assign keycode
In Konsole, execute the following commands:
xmodmap -e 'keycode 101 = XF86LaunchD'
xmodmap -e 'keycode 212 = XF86LaunchE'

2. Assign some KDE global shortcuts
- start System Settings
- go to "Keyboard & Mouse", select "Keyboard Shortcuts" section
- in "Shortcuts Schemes", check that you are in "Global Shortcuts" tabe
- find "Maximize Window" action (in "Windows" section)
- select it and in the bottom of screen select "Custom" or click on button
with "None" label
- dialog will open, now press appropriate brightness key (up or down)
- XF86LaunchD or XF86LaunchE should be entered
  (if not, check step 1.)
- click "Apply" button

3. Test newly assigned key
- ensure that you have one window set as current
- press assigned key -> window should maximize

If the first key works, please repeat step 2. and 3. with the second
brightness key, to test both xkeysym assignments.
When I get some reports (positive or negative), we can debug this further.

You can also try to reach me on IRC in #kubuntu-devel - just ping Lure.

Regards,
Luka"

[dresnu (dresnu)]

It *almost* works. I assign both keys to maximize explained. When I try to maximize a window I can see it get bigger but then it instantly turns back to the size it had before.
Same effect with both key combination.

[Luka Renko (lure)]

Maximize is toggle action - so it may be that two presses were registered. You can check with if you run "xev" and check its output.

[Ryan P. Bitanga (ephebiphobic)]

Luka,

You have a typo in your sources. It doesn't work because these lines:

              { "BrightnessUp", KShortcut("XF86Launch1", SLOT(pmBrightnesUp()) },
              { "BrightnessDown", KShortcut("XF86Launch2"), SLOT(pmBrightnesDown()) },

are supposed to be these linese:
              { "BrightnessUp", KShortcut("XF86Launch1"), SLOT(pmBrightnessUp()) },
              { "BrightnessDown", KShortcut("XF86Launch2"), SLOT(pmBrightnessDown()) },

Notice the missing "s"...

It most probably had nothing to do with your choice of key bindings.

Hope that helps.

[Luka Renko (lure)]

Ryan, sure it helps. ;-) Thank you very much for catching this!

I have uploaded new kdeutils/kdebase packages to my PPA (gutsy) and they should be built in couple of hours. When I get at least some confirmation that it works for some reporters (do not forget to logout/login!), I will prepare Hardy packages (as they are prerequisite to start SRU process).

[Luka Renko (lure)]

Packages are now available in my PPA. Add this to your sources.list:

deb http://ppa.launchpad.net/lure/ubuntu gutsy main

After update/upgrade, do logout/login (or reboot) and test brightness keys.

[dragon76 (tfishwall)]

Just tried the rebuilt packages. Brightness down works but not brightness up.

[Ryan P. Bitanga (ephebiphobic)]

I didn't download Luka's packages but changing those lines causes the brightness keys to work on my machine. Check your /usr/share/apps/kxkb/ubuntu.xmodmap.

Add the XF86Launch1 and XF86Launch2 lines if they don't exist. Something like:

keycode 101 = XF86Launch2
keycode 212 = XF86Launch1

I wasn't sure which package was in charge of fixing ubuntu.xmodmap so I had to edit it myself.

[Ryan P. Bitanga (ephebiphobic)]

The only problem for me now is the brightness popup of guidance-power-manager is ugly. I have kmilo-legacy installed so the asus plug-in shows the kmilo osd. Wish we could disable the popup from guidance-power-manager. Nothing is exposed via dcop so it has to be edit in guidance-power-manager itself.

[Luka Renko (lure)]

dragon76: does dcop calls works? Can you again test the stuff from comment #37

Ryan: I have changed back mapping for Down to XF86LaunchD and Up to XF86LaunchE
We can work on better popup for Hardy.

[dragon76 (tfishwall)]

Luka: I retested the dcop calls and they work fine.

[ThomasN (tnetter)]

No success on my HP2510p.
Downloaded Luka's updated packages. Logout/Login. Screen brightness
buttons still don't work.
Also tried Ryan's xmodmaps to XF86Launch1 and XF86Launch2. No change in
brightness.

Brightness buttons work in Gnome, nevertheless. xev keycodes correspond to:
keycode 101 = XF86LaunchD
keycode 212 = XF86LaunchE
just as specified in ubuntu.xmodmap.

Here's what xev gives in KDE and then Gnome when pressing the brightness
buttons. Notice the strange FocusOut events in KDE. These are burst
every time I press on the Decrease brightness button.

KDE

*** Decrease brightness (does not work):

FocusOut event, serial 34, synthetic NO, window 0x2a00001,
    mode NotifyGrab, detail NotifyAncestor

FocusOut event, serial 34, synthetic NO, window 0x2a00001,
    mode NotifyUngrab, detail NotifyPointer

FocusIn event, serial 34, synthetic NO, window 0x2a00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 34, synthetic NO, window 0x0,
    keys: 2 0 0 0 0 0 0 0 0 0 0 0 32 0 0 0
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

KeyRelease event, serial 34, synthetic NO, window 0x2a00001,
    root 0x67, subw 0x0, time 1512701644, (169,116), root:(173,143),
    state 0x0, keycode 101 (keysym 0x1008ff4d, XF86LaunchD), same_screen
YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

*** Increase brightness (does not work)

KeyPress event, serial 34, synthetic NO, window 0x2a00001,
    root 0x67, subw 0x0, time 1512769429, (167,144), root:(171,171),
    state 0x0, keycode 212 (keysym 0x1008ff4e, XF86LaunchE), same_screen
YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2a00001,
    root 0x67, subw 0x0, time 1512769429, (167,144), root:(171,171),
    state 0x0, keycode 212 (keysym 0x1008ff4e, XF86LaunchE), same_screen
YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

GNOME

*** Decrease brightness (works)
KeyPress event, serial 30, synthetic NO, window 0x3a00001,
    root 0x67, subw 0x0, time 1513092409, (1,169), root:(594,193),
    state 0x0, keycode 101 (keysym 0x1008ff4d, XF86LaunchD), same_screen
YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3a00001,
    root 0x67, subw 0x0, time 1513092409, (1,169), root:(594,193),
    state 0x0, keycode 101 (keysym 0x1008ff4d, XF86LaunchD), same_screen
YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

*** Increase brightness (works)
 KeyPress event, serial 30, synthetic NO, window 0x3a00001,
    root 0x67, subw 0x0, time 1513143284, (6,168), root:(599,192),
    state 0x0, keycode 212 (keysym 0x1008ff4e, XF86LaunchE), same_screen
YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3a00001,
    root 0x67, subw 0x0, time 1513143284, (6,168), root:(599,192),
    state 0x0, keycode 212 (keysym 0x1008ff4e, XF86LaunchE), same_screen
YES,
   ...

[dragon76 (tfishwall)]

Issue is fixed in Hardy 8.04 alpha with kernel 2.6.24-2-generic and 2.6.24-3-generic. At least on my Everex where I have been running Hardy.

[kstanoev (civ-mail)]

I upgraded from Xubuntu 7.04 to 7.10 and the Fn key combos on my Toshiba Satellite L40-12K stopped working, including the brightness adjusting ones. Also Xfce's Ctrl+Esc shortcut doesn't work now, it works maybe once in 20 tries. This is also the case with a fresh install of Xubuntu 7.10.

[Alexander Blinne (sunday)]

Issue is fixed, kmilo now receives fakekey-events and forwards to guidance-power-manager by a dcop call. guidance uses dbus in order to tell hald to actually change brightness.

changelog entry:

kdeutils (4:3.5.8-1ubuntu7) hardy; urgency=low

  * debian/patches/kubuntu_14_kmilo_powermanager.diff:
    Added Brightness Down & Up key actions (DCOP call to Guidance
    Power-Manager). Fixed all DCOP calls to recent change of
    application top level name (power-manager -> guidance).

 -- Luka Renko < <email address hidden>> Sun, 10 Feb 2008 20:45:42 +0100

Workaround for gutsy:

edit scripts in /etc/acpi to use dcop-calls instead of acpi_fakekey.
the dcop-commands by luka renko sometimes don't work until acpid is manually restarted (dcop can't attach to server).
the following calls work better as i see it:

dcop --all-sessions --all-users power-manager-`ps ax|grep -m 1 guidance|awk '{ print $1 }'` power-manager brightnessUp
dcop --all-sessions --all-users power-manager-`ps ax|grep -m 1 guidance|awk '{ print $1 }'` power-manager brightnessDown

I think this bug could now be closed.

[Tomas Zilvar (jcd17)]

Will the patch make it to Gutsy's repositories? Or some other solution? It's weird to close a bug with a "workaround" of this sort... And it's a shame that after half a year it's still present, I've spent too much time figuring this out after a flawless fresh install on my HP 6510b.

[der_vegi (m-may)]

It worked for me (using Gnome) for some months, but now it is broken again, see bug 105512.

[der_vegi (m-may)]

Maybe this fix from Dov-El works for you as well? It worked for me, but I am not on Kde:

"The fix is found @ http://www.ubuntu1501.com/2008/04/overview-of-ubuntu-804-hardy-heron-on.html . and was blogged by aaronmt (http://www.blogger.com/profile/00032734089773880467).

<quote>
To fix brightness, it's easy as just editing two script files. No bios change whatsoever.

sudo gedit /etc/acpi/video_brightnessup.sh

replace everything in the file with

#!/bin/bash

CURRENT=$(grep "current:" /proc/acpi/video/VGA/LCD/brightness |awk '{print $2}')

case "$CURRENT" in

100)
echo -n 100 > /proc/acpi/video/VGA/LCD/brightness;
;;
87)
echo -n 100 > /proc/acpi/video/VGA/LCD/brightness;
;;
75)
echo -n 87 > /proc/acpi/video/VGA/LCD/brightness;
;;
62)
echo -n 75 > /proc/acpi/video/VGA/LCD/brightness;
;;
50)
echo -n 62 > /proc/acpi/video/VGA/LCD/brightness;
;;
37)
echo -n 50 > /proc/acpi/video/VGA/LCD/brightness;
;;
25)
echo -n 37 > /proc/acpi/video/VGA/LCD/brightness;
;;
12)
echo -n 25 > /proc/acpi/video/VGA/LCD/brightness;
;;
*)
echo -n 100 > /proc/acpi/video/VGA/LCD/brightness ;
;;
esac

sudo gedit /etc/acpi/video_brightnessdown.sh

replace everything in the file with

#!/bin/bash

CURRENT=$(grep "current:" /proc/acpi/video/VGA/LCD/brightness |awk '{print $2}')

case "$CURRENT" in

12)
echo -n 12 > /proc/acpi/video/VGA/LCD/brightness;
;;
25)
echo -n 12 > /proc/acpi/video/VGA/LCD/brightness;
;;
37)
echo -n 25 > /proc/acpi/video/VGA/LCD/brightness;
;;
50)
echo -n 37 > /proc/acpi/video/VGA/LCD/brightness;
;;
62)
echo -n 50 > /proc/acpi/video/VGA/LCD/brightness;
;;
75)
echo -n 62 > /proc/acpi/video/VGA/LCD/brightness;
;;
87)
echo -n 75 > /proc/acpi/video/VGA/LCD/brightness;
;;
100)
echo -n 87 > /proc/acpi/video/VGA/LCD/brightness;
;;
*)
echo -n 50 > /proc/acpi/video/VGA/LCD/brightness ;
;;
esac

</quote>"

[Jonathan Thomas (echidnaman)]

KMilo no longer exists in Intrepid/KDE4 -> invalidating.

[Jonathan Thomas (echidnaman)]

Doesn't really affect kdebase either, more of a guidance-power-manager bug, if the bug still exists at all. Does it?

[Jonathan Thomas (echidnaman)]

Oh, I see from the comments that this works with guidance-power-manager.

[Tommy_CZ (t-kijas)]

I was redirected here from bug #140652, that is duplicate of this bug. I have macbook air 2012, and brighness, battery report etc. doesn't work in KDE, but works in Unity.