When I'm on battery, I let xfce4-power-manager dim the backlight when the computer is idling; but when I move the mouse, the brightness is set to an arbitrary level, not to the one I set before the idle (in fact, on my netbook the brightness is set too low, which is pretty annoying...) The backlight should be set to the original brightness, or alternatively it should be possible to decide the brightness level on battery and on AC (maybe even on idle? Don't know if it'd make sense) Cheers, Luca
(In reply to comment #0) > When I'm on battery, I let xfce4-power-manager dim the backlight when the > computer is idling; but when I move the mouse, the brightness is set to an > arbitrary level, not to the one I set before the idle (in fact, on my netbook > the brightness is set too low, which is pretty annoying...) > The backlight should be set to the original brightness, or alternatively it > should be possible to decide the brightness level on battery and on AC (maybe > even on idle? Don't know if it'd make sense) > Cheers, > > Luca xfpm is programmed to set the brightness to the original value when you move the mouse or you press the keyboard, now as you say it is not the case it sounds strange to me and probably you have some problem related to HAL. To go further what is the laptop model that is having this problem, you said a netbook, which one. Also please attach the output of lshal here. Thanks for your report.
Created attachment 2566 Output of lshal
(In reply to comment #1) > xfpm is programmed to set the brightness to the original value when you move > the mouse or you press the keyboard, now as you say it is not the case it > sounds strange to me and probably you have some problem related to HAL. > > To go further what is the laptop model that is having this problem, you said a > netbook, which one. It's an eee 901, the kernel version is 2.6.29 and HAL's is 0.5.13 > Also please attach the output of lshal here. Attached Thank you Luca
Ok, nothing strange. Please do the following steps: 1) Put you lcd to its maximum brightness level 2) run dbus-send --print-reply --system --dest=org.freedesktop.Hal \ > /org/freedesktop/Hal/devices/computer_backlight \ > org.freedesktop.Hal.Device.LaptopPanel.GetBrightness 3) Reduce it with one level then rerun the above command. 4) try to set it to its minimum value then rerun the above command. Of course each command will print you the brightness that HAL actually knows about, please write them down to post here.
(In reply to comment #4) > Of course each command will print you the brightness that HAL actually knows > about, please write them down to post here. Minimum 0, maximum 15
Ok, I got it wrong: it doesn't set the backlight always to the same level: it sets it back to the level it was set to at log-in time (at the time xfce4-power-manager was started I guess). So if I log in, and then change brightness, the change gets lost after the first idle period.
(In reply to comment #6) > So if I log in, and then change brightness, the change gets lost after the > first idle period. You change your brightness level after log in and xfpm is running? your problem is still not clear to me.
(In reply to comment #7) > You change your brightness level after log in and xfpm is running? your problem > is still not clear to me. Example: At boot time brightness level is 3. I log in (xfpm is started). I change the brightness to 5, the I stay idle for 30 seconds and the backlight is dimmed by xfpm. I move the mouse again, brightness level is set to 3. I suppose this could be related to the fact that when I change the brightness using the hotkeys no keycode is generated (and xfpm doesn't show the OSD with the brightness level that I saw on an other laptop), so maybe it doesn't record the new level. The workaround would be reading the actual level just before dimming. Cheers, Luca P.S. I now tried with a laptop that generates the keycodes, and xfpm works as expected, so I guess that is the problem
(In reply to comment #8) > I now tried with a laptop that generates the keycodes, and xfpm works as > expected, so I guess that is the problem Yes, in your case the brightness keys are not mapped by HAL neither X. Your workaround is already added since 0.8.0, but the problem here is that xfpm reads the actual brightness from HAL, HAL doesn't automatically updates the brightness info when the user changes the brightness with fn keys unless it was told to, so in normal situation: 1) brightness key pressed. 2) xfpm catches the event and send it to HAL 3) HAL then updates the brightness level bit. 4) xfpm reads back when needed the last HAL brightness bit. I now this sucks, but HAL works that way, you see, step 2 is missing in your case. I will close this bug as invalid (don't take it negative as people usually do, it is a valid bug, but not an xfpm one, and i can do nothing to fix it on the xfpm side), many thanks for your report, but i will be pleased to help if needed, hopefully you can try somehow to convince HAL to map these keys.
(In reply to comment #9) > 1) brightness key pressed. > 2) xfpm catches the event and send it to HAL > 3) HAL then updates the brightness level bit. > 4) xfpm reads back when needed the last HAL brightness bit. There's one thing that doesn't seem to fit: if I call org.freedesktop.Hal.Device.LaptopPanel.GetBrightness via dbus-send, I always get the correct actual brightness (i.e. it gets updated after I use the hotkeys). So Hal does know it...
Created attachment 2576 Store the actual brightness level before dimming. Yes, if the above method returning the actual brightness then i'm wrong, please try the attached patch. re-opened.
(In reply to comment #11) > Yes, if the above method returning the actual brightness then i'm wrong, please > try the attached patch. re-opened. The patch does it. Thanks for your attentive bug-care! Luca
(In reply to comment #12) > The patch does it. > Thanks for your attentive bug-care! > Luca Thanks for your report and input.