Description of problem: Using hotkeys to change brigthness cause level to be changed two levels instead one, as key combination was pressed two times. This was seen on a Acer Aspire 2920. Version-Release number of selected component (if applicable): How reproducible: Every time you change backlight level using default hotkey combination (usually Fn+Left & Fn+Right). Sometimes happen when using power applet. Steps to Reproduce: 1.Press Fn+Left or Fn+Right (brightness up or down) to change brightness. 2.At each keypress, brightness level changes 2 steps, up or down. 3.Sometimes, the brightness change resets itself back to powerdevil saved level. 4.If you keep Fn key pressed then change brightness several times back and forth, you see the level going back to profile value then back to value you is setting. 5.Sometimes the level is changed when keys are pressed down then changed one more level when keys are released.
@ AL13N I know you have a different Acer Aspire, but can you change the backlight level with Fn+left and Fn+right, too? If so, does it work well with you?
CC: (none) => alien, marja11
it seems to me that it's not 2 steps up/down, but more that it seems there are 10 possible settings for brightness and there is more divisions in the graphic component on KDE, perhaps it's something like this? i mean, if i am at max brightness, i can move 9 times down, until it don't change anymore. and again 9 times up. holding key down and release doesn't do an extra thing for me. for myself this is sufficient, i donno if more than 10 steps are required?
(In reply to comment #1) > @ AL13N > > I know you have a different Acer Aspire, but can you change the backlight level > with Fn+left and Fn+right, too? > If so, does it work well with you? It happens when using the hotkeys ONLY. KDE applet changes brigtness as expected. Both ways change brightness (i.e. talking to ACPI control is working).
(In reply to comment #2) > it seems to me that it's not 2 steps up/down, but more that it seems there are > 10 possible settings for brightness and there is more divisions in the graphic > component on KDE, perhaps it's something like this? This is another thing. I could see it sometimes. > > i mean, if i am at max brightness, i can move 9 times down, until it don't > change anymore. and again 9 times up. > Yes, I confirmed it. It is annoyng, but not as this bug. > holding key down and release doesn't do an extra thing for me. I updated the BIOS to latest version (currently 1.13) at ACER site. Maybe the newer version has [more] bugs in it's ACPI implementation. > > for myself this is sufficient, i donno if more than 10 steps are required? I changed my distro back to Mandriva 2010.2 (32 bit) to do more testing. For each Fn+Left/Fn+Right keypress combination, the backlight results are interesting: (I started at a medium brightness going down, then back to up) [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 4 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 2 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 0 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 2 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 4 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 6 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 8 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 9 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 9 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 7 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 5 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 3 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 1 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 0 [root@localhost luzemario]# cat /sys/class/backlight/acpi_video0/brightness 0 There are 10 steps, numbered from 0 to 9. In Mandriva, all changes made two steps. When it reaches maximum or minimum, it changes only the allowed (i.e the one remaining) step. I can go down for odd numers and up for even numbers and vice-versa. Maybe the setting did changing twice, but I can't notice it. But in Mageia 1, each level change takes half seconf, and I can clearly notice TWO level changes. BTW, x86_64 system appears to be slower than 32 bit system. I am downloading Mageia x86_32 to confirm if it behaves like Mandriva.
i didn't update BIOS i definately don't have your issue (even though my ACER is diff model)
FYI: on some laptops you will need to add "acpi_backlight=vendor" to the kernel boot parameters to get proper backlight support - maybe this also works in your case.
CC: (none) => lohmaier+mageia
(In reply to comment #6) > FYI: on some laptops you will need to add "acpi_backlight=vendor" to the kernel > boot parameters to get proper backlight support - maybe this also works in your > case. @ Luzemário Did you try this? If so, did it help?
Well, I saw this bug report in KDE buzilla, so it could be an upstream thing https://bugs.kde.org/show_bug.cgi?id=276482 @ Luzemário Does the problem occur, regardless of which Desktop environment you use, or is it only in KDE?
CC: (none) => balcaen.john
@ Luzemário Please reply to the questions in comment 7 and comment 8 within two weeks from now, to avoid this bug being closed as OLD.
Keywords: (none) => NEEDINFO
(In reply to comment #7) > > FYI: on some laptops you will need to add "acpi_backlight=vendor" to the kernel > > boot parameters to get proper backlight support - maybe this also works in your > > case. > > @ Luzemário > > Did you try this? If so, did it help? Hi Marja, sorry for delay. No, it does not work. Using acpi_backlight=vendor completely disables ACPI control from KDE. Both hotkeys and APCI buttons (power, standby, etc) cease to work. I installed i586 version of Mageia, and my hope is confirmed. With 32 bit version, Mageia behaves like Mandriva (two-sptep change, but at least I can change it smoothly). 64-bit version of Mageia has a greater lag between ACPI events processing, causing sometimes KDE to go crazy. Pressing a bunch of ACPI keystrokes can cause system to go into a endless loop of keys being repeated.
In 64-bit version, pressing ACPI power button to shutdown system (if configured to do so) takes one minute or more, freezing KDE task manager. I am sometimes rushed, then I switch to console to issue a INIT 0 as root to system finally shutdown. This does not happen in i586 Mageia.
(In reply to comment #8) > @ Luzemário > > Does the problem occur, regardless of which Desktop environment you use, or is > it only in KDE? It makes no difference. I use LXDE toghether with KDE, and brightness levels change twice for each keypress in LXDE too. Despite changes from DEs, I can set brightness manually within a root terminal: [root@acer luzemario]# cat /sys/class/backlight/acpi_video0/brightness 3 [root@acer luzemario]# echo 6 > /sys/class/backlight/acpi_video0/brightness [root@acer luzemario]# echo 5 > /sys/class/backlight/acpi_video0/brightness [root@acer luzemario]# echo 4 > /sys/class/backlight/acpi_video0/brightness --> works OK from level 0 to 9 both upwards and downwards, as expected.
> > I installed i586 version of Mageia, and my hope is confirmed. With 32 bit > version, Mageia behaves like Mandriva (two-sptep change, but at least I can > change it smoothly). > > 64-bit version of Mageia has a greater lag between ACPI events processing, > causing sometimes KDE to go crazy. Pressing a bunch of ACPI keystrokes can > cause system to go into a endless loop of keys being repeated. (In reply to comment #11) > In 64-bit version, pressing ACPI power button to shutdown system (if configured > to do so) takes one minute or more, freezing KDE task manager. I am sometimes > rushed, then I switch to console to issue a INIT 0 as root to system finally > shutdown. This does not happen in i586 Mageia. Is this the same, for LXDE, too? (Thanks for you replies, btw)
Yes, it is the same for LXDE and INIT 3 too. Is not a DM issue.
@ Luzemário Thanks :) About the first, original issue of this bug: Changing brightness from the console works fine, I'm wondering now whether adjusting a few lines in /lib/udev/keymaps/acer would help (although I can't see what is wrong with the lines that I see in that file on my system) Can you run xev | tee xevoutput.txt in a konsole, use your brightness hotkeys to change the brightness, stop xev by shutting the little white screen that has appeared, and then attach xevoutput.txt to this bug report? Can you also run tailf /var/log/messages 2>&1 | tee output.txt use the hotkeys to change the brightness and attach output.txt here, too? cc'ing some udev committers ******************************************************************************** Now about the second issue: (In reply to comment #13) > > (In reply to comment #11) > > In 64-bit version, pressing ACPI power button to shutdown system (if configured > > to do so) takes one minute or more, freezing KDE task manager. I am sometimes > > rushed, then I switch to console to issue a INIT 0 as root to system finally > > shutdown. This does not happen in i586 Mageia. > > Is this the same, for LXDE, too? (Thanks for you replies, btw) (In reply to comment #14) > Yes, it is the same for LXDE and INIT 3 too. Is not a DM issue. Do you mind opening a new bug report for that issue? (I just checked and AFAICS it hasn't been reported yet by anyone else) Please attach, after this happened again, the relevant part of /var/log/messages to that new bug report
CC: (none) => dmorganec, mageia, thierry.vignaudSource RPM: (none) => udev
Created attachment 1440 [details] Output of xev command with brightness keys pressed once a event Pressed and hold Fn then pressed each key at once, several times up then down, without releasing Fn key.
Created attachment 1441 [details] Output of 'tailf /var/log/messages 2>&1 | tee output.txt' Output of error message log. Note, there are no messages added when making keypresses.
(In reply to comment #15) > Can you run > xev | tee xevoutput.txt > in a konsole, use your brightness hotkeys to change the brightness, stop xev by > shutting the little white screen that has appeared, and then attach > xevoutput.txt to this bug report? > Done, see attachment. > Can you also run > tailf /var/log/messages 2>&1 | tee output.txt > use the hotkeys to change the brightness and attach output.txt here, too? > Done, see attachment. > Do you mind opening a new bug report for that issue? (I just checked and AFAICS > it hasn't been reported yet by anyone else) Agreed. Will be done as so.
Thanks :) If there is anything wrong with the xev output, I don't see it :( Seems I was thinking in a wrong direction, it seemed so easy: add a /lib/udev/keymaps/acer-aspire_2920 with a few lines and something in the keyboard force release rules. I can't find the KDE applet you used to change your screen brightness with. Where is it hidden? (Or what name has it got) I want to check how many brightness steps I have with that applet Assigning this bug to kernel and its maintainer. @ tmb Please assign back if I'm wrong to do so
Assignee: bugsquad => tmbSource RPM: udev => kernel
Keywords: NEEDINFO => (none)
This message is a reminder that Mageia 1 is nearing its end of life. In approximately 25 days from now, Mageia will stop maintaining and issuing updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '1'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 1's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 1 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => WONTFIX