| Summary: | Brigthness hotkeys change level twice for a single keypress combination | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Luzemário Dantas <luzemario> |
| Component: | RPM Packages | Assignee: | Thomas Backlund <tmb> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | Normal | CC: | alien, balcaen.john, dmorganec, lohmaier+mageia, mageia, marja11, thierry.vignaud |
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kernel | CVE: | |
| Status comment: | |||
| Attachments: |
Output of xev command with brightness keys pressed once a event
Output of 'tailf /var/log/messages 2>&1 | tee output.txt' |
||
|
Description
Luzemário Dantas
2011-06-08 20:51:40 CEST
@ 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.vignaud 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 =>
tmb
Marja Van Waes
2012-02-11 15:46:23 CET
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 =>
RESOLVED |