Brightness key stopped working after update [Gutsy]
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gnome-power-manager (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
guidance-power-manager (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
kdebase (Ubuntu) |
Invalid
|
Medium
|
Luka Renko | ||
kdeutils (Ubuntu) |
Invalid
|
Medium
|
Luka Renko |
Bug Description
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/
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-
Thomas Sommer (flightsupport) wrote : | #1 |
Francisco Borges (francisco-borges) wrote : | #2 |
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/
[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) wrote : | #3 |
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) wrote : | #4 |
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-
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) wrote : | #5 |
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)
Changed in kdebase: | |
status: | New → Invalid |
Changed in gnome-power-manager: | |
status: | New → Fix Released |
Kyle S (pissboy) wrote : Re: [Bug 145337] Re: Brightness key stopped working after update [Gutsy] | #6 |
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-
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) wrote : | #7 |
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) wrote : | #8 |
Changed in gnome-power-manager: | |
status: | Fix Released → Confirmed |
Kyle S (pissboy) wrote : | #9 |
> ** 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) wrote : | #10 |
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) wrote : | #11 |
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/
Nevertheless, I think it is *very* counter-productive to un-mark a bug
report on kde-base and then remark it as gnome-power-
wrong.
There are multiple reports that it is failing on kde-base, so based on
which fact this now ONLY applies to gnome-power-
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-
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) wrote : | #12 |
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-
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) wrote : | #13 |
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) wrote : | #14 |
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-
guidance-
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) wrote : | #15 |
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/
Do you all have ATI Radeon cards? I have an ' ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP]'.
Francisco Borges (francisco-borges) wrote : | #16 |
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-
5117 ? S 0:00 \_ /usr/lib/
5118 ? S 0:00 \_ hald-addon-acpi: listening on acpid socket /var/run/
5119 ? S 0:00 \_ hald-addon-
5120 ? S 0:00 \_ hald-addon-
5121 ? S 0:00 \_ hald-addon-
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
Changed in kdebase: | |
status: | Invalid → Confirmed |
der_vegi (m-may) wrote : | #17 |
This reminds me of some curiosity I experienced in Feisty: Executing the command 'echo -n 62 > /proc/acpi/
I can't reproduce this on Gutsy, though.
Alexander Hunziker (alex-hunziker) wrote : | #18 |
As of today, brightness setting fully works for me on a T60. Anyone confirming that?
Kyle S (pissboy) wrote : | #19 |
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) wrote : | #20 |
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) wrote : | #21 |
Still not working on Gnome for me, all updates until now (Oct. 13th) installed... Dell Inspiron 1501.
racoon97 (racoon97) wrote : | #22 |
Dont't work for me too, Dell Inspiron 1501.
der_vegi (m-may) wrote : | #23 |
Maybe that information helps: When I try to use the gnome-brightnes
Thiago Teixeira (tvst) wrote : | #24 |
i'm having the same problem on a thinkpad t60.
just so you know, this bug [url=http://
hopefully someone will fix this soon.
Thiago Teixeira (tvst) wrote : | #25 |
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://
hopefully someone will fix this soon.
Loic Nageleisen (lloeki) wrote : | #26 |
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/
- pressing keys does not change brightness in KDE or on console, 'cat /proc/acpi/
- changing brightness settings in KDE power management settings works, and 'cat /proc/acpi/
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) wrote : | #27 |
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/
/etc/acpi/
use xev and 'lshal -m')
These scripts only call "/usr/bin/
So the problem seems to be on the "acpi-support" package.
kind regards,
--
Francisco
Kyle S (pissboy) wrote : | #28 |
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-
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-
> 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) wrote : | #29 |
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.
Changed in gnome-power-manager: | |
status: | Confirmed → Invalid |
VictorArguelles (v-arguelles) wrote : | #30 |
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) wrote : | #31 |
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) wrote : | #32 |
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) wrote : | #33 |
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) wrote : | #34 |
I can confirm that the bug is also present in kpowersave in addition to kpowermanager.
mikelopez (e-mikelopez) wrote : | #35 |
- Workaround script Edit (696 bytes, text/x-sh)
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/
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/
my video_brightnes
#!/bin/bash
. /usr/share/
#acpi_fakekey $KEY_BRIGHTNESSUP
lcdbryt.sh up
and my video_brightnes
#!/bin/bash
. /usr/share/
#acpi_fakekey $KEY_BRIGHTNESSDOWN
lcdbryt.sh dn
Marc Carson (baggageclaim) wrote : | #36 |
mikelopez: Thanks for the script. I got it working, but I had to change "/proc/
Luka Renko (lure) wrote : | #37 |
Can each of reporters that have problem on Kubuntu Gutsy report back the following info for their laptop:
1. Exact HW
cat /var/lib/
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:/
Changed in kdebase: | |
assignee: | nobody → lure |
status: | Confirmed → Incomplete |
Mikael Gerdin (mgerdin) wrote : | #38 |
* 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_
platform_
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/
Revenant (hasana) wrote : | #39 |
1. Exact HW
cat /var/lib/
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:/
Yes, it does and "lshal -m" reports the following :
Start monitoring devicelist:
-------
22:17:45.437: platform_
22:17:46.116: platform_
I hope it will help in resolving this issue.
dragon76 (tfishwall) wrote : | #40 |
1. Everex StepNote ST5340T
2. The dcop commands work
3. brightness up = 212
brightness down = 101
Just in case it helps: lsmod -m
platform_
platform_
Kyle S (pissboy) wrote : | #41 |
> 1. Exact HW
ThinkPad T60
> cat /var/lib/
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-
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_
ButtonPressed = brightness-up
18:17:49.848: platform_
ButtonPressed = brightness-down
HTH!
Marc Carson (baggageclaim) wrote : | #42 |
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_
15:50:44.901: platform_
15:50:45.527: platform_
15:50:45.561: platform_
Luka Renko (lure) wrote : | #43 |
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.
Changed in kdeutils: | |
assignee: | nobody → lure |
importance: | Undecided → Medium |
status: | New → In Progress |
Changed in kdebase: | |
importance: | Undecided → Medium |
status: | Incomplete → In Progress |
Luka Renko (lure) wrote : | #44 |
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/
deb http://
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) wrote : | #45 |
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/
>
> deb http://
>
> 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) wrote : | #46 |
The fix isn't working for me either, but it seems that with the package versions in http://
Martin Böhm (martin.bohm) wrote : | #47 |
It doesn't work here either (MacBook).
Luka Renko (lure) wrote : | #48 |
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) wrote : | #49 |
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) wrote : | #50 |
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) wrote : | #51 |
I upgraded ny system using deb http://
My fn-brightness still doing nothing.
Revenant (hasana) wrote : | #52 |
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) wrote : | #53 |
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_
ButtonPressed = brightness-up
09:41:08.377: platform_
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://
Francisco Borges (francisco-borges) wrote : | #54 |
> 1. Exact HW
> cat /var/lib/
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://
after a reboot.
HTH, and thanks a lot for looking into this problem
--
Francisco
VictorArguelles (v-arguelles) wrote : | #55 |
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://
Tim Aretz (tim-aretz) wrote : | #56 |
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:/
Yes,
212 NoSymbol
102 NoSymbol
lshal:
12:04:44.849: platform_
12:04:46.936: platform_
Tim Aretz (tim-aretz) wrote : | #57 |
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) wrote : | #58 |
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:/
Toshiba is not reported on that page but I get those keycodes (212-101) if I run xev
Andi (andithese) wrote : | #59 |
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/
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:/
19:34:08.983: platform_
19:34:09.413: platform_
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) wrote : | #60 |
I use kubuntu from gutsy. The brightness keys used to work on feisty, and stopped after an upgrade yesterday.
$ cat /var/lib/
8743CTO
The dcop scripts don't work for me
$ lshal -m
Start monitoring devicelist:
-------
00:26:54.354: platform_
00:26:56.291: platform_
By echo'ing values to /proc/acpi/
psartini (piero-sartini) wrote : | #61 |
>Can each of reporters that have problem on Kubuntu Gutsy report back the following info for their laptop:
>1. Exact HW
> cat /var/lib/
(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/
>3. Does your laptop return same keycodes from brightness up (212) and down (101) as documented on
> https:/
yes
ThomasN (tnetter) wrote : | #62 |
1. Exact HW
cat /var/lib/
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:/
Answer: Here's the output of lshal -m
Start monitoring devicelist:
-------
16:54:21.186: platform_
16:54:24.172: platform_
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) wrote : | #63 |
I have started a thread in kubuntu-devel mailing list for further debugging. If you want to participate, join the discussion there:
https:/
I will also report any progress in the bug.
Rodrigo (rowdrigo) wrote : | #64 |
In message at https:/
"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) wrote : | #65 |
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) wrote : | #66 |
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) wrote : | #67 |
Luka,
You have a typo in your sources. It doesn't work because these lines:
{ "BrightnessUp", KShortcut(
{ "BrightnessDown", KShortcut(
are supposed to be these linese:
{ "BrightnessUp", KShortcut(
{ "BrightnessDown", KShortcut(
Notice the missing "s"...
It most probably had nothing to do with your choice of key bindings.
Hope that helps.
Luka Renko (lure) wrote : | #68 |
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) wrote : | #69 |
Packages are now available in my PPA. Add this to your sources.list:
deb http://
After update/upgrade, do logout/login (or reboot) and test brightness keys.
dragon76 (tfishwall) wrote : | #70 |
Just tried the rebuilt packages. Brightness down works but not brightness up.
Ryan P. Bitanga (ephebiphobic) wrote : | #71 |
I didn't download Luka's packages but changing those lines causes the brightness keys to work on my machine. Check your /usr/share/
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) wrote : | #72 |
The only problem for me now is the brightness popup of guidance-
Luka Renko (lure) wrote : | #73 |
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) wrote : | #74 |
Luka: I retested the dcop calls and they work fine.
ThomasN (tnetter) wrote : | #75 |
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) wrote : | #76 |
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) wrote : | #77 |
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) wrote : | #78 |
Issue is fixed, kmilo now receives fakekey-events and forwards to guidance-
changelog entry:
kdeutils (4:3.5.8-1ubuntu7) hardy; urgency=low
* debian/
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) wrote : | #79 |
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) wrote : | #80 |
It worked for me (using Gnome) for some months, but now it is broken again, see bug 105512.
der_vegi (m-may) wrote : | #81 |
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://
<quote>
To fix brightness, it's easy as just editing two script files. No bios change whatsoever.
sudo gedit /etc/acpi/
replace everything in the file with
#!/bin/bash
CURRENT=$(grep "current:" /proc/acpi/
case "$CURRENT" in
100)
echo -n 100 > /proc/acpi/
;;
87)
echo -n 100 > /proc/acpi/
;;
75)
echo -n 87 > /proc/acpi/
;;
62)
echo -n 75 > /proc/acpi/
;;
50)
echo -n 62 > /proc/acpi/
;;
37)
echo -n 50 > /proc/acpi/
;;
25)
echo -n 37 > /proc/acpi/
;;
12)
echo -n 25 > /proc/acpi/
;;
*)
echo -n 100 > /proc/acpi/
;;
esac
sudo gedit /etc/acpi/
replace everything in the file with
#!/bin/bash
CURRENT=$(grep "current:" /proc/acpi/
case "$CURRENT" in
12)
echo -n 12 > /proc/acpi/
;;
25)
echo -n 12 > /proc/acpi/
;;
37)
echo -n 25 > /proc/acpi/
;;
50)
echo -n 37 > /proc/acpi/
;;
62)
echo -n 50 > /proc/acpi/
;;
75)
echo -n 62 > /proc/acpi/
;;
87)
echo -n 75 > /proc/acpi/
;;
100)
echo -n 87 > /proc/acpi/
;;
*)
echo -n 50 > /proc/acpi/
;;
esac
</quote>"
Jonathan Thomas (echidnaman) wrote : | #82 |
KMilo no longer exists in Intrepid/KDE4 -> invalidating.
Changed in kdeutils: | |
status: | In Progress → Invalid |
Jonathan Thomas (echidnaman) wrote : | #83 |
Doesn't really affect kdebase either, more of a guidance-
Changed in kdebase: | |
status: | In Progress → Invalid |
Changed in guidance-power-manager: | |
status: | New → Incomplete |
Jonathan Thomas (echidnaman) wrote : | #84 |
Oh, I see from the comments that this works with guidance-
Changed in guidance-power-manager: | |
status: | Incomplete → Fix Released |
Tommy_CZ (t-kijas) wrote : | #85 |
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.
Same problem here with Ubuntu Gutsy on a Dell Inspiron 640m/E1405.
Brightness-down works, Brightness-up does not.