Sorry, forgot to add:

This has been happening with all of the 2.15.x releases

What does 'lshal | grep levels' print?

andy@shiny ~ $ lshal | grep levels
  laptop_panel.num_levels = 14  (0xe)  (int)

14 levels means that g-p-m should use brightness states 0-13.

I think this is a hal bug where laptop_panel.num_levels should equal 15.

Can you try setting laptop_panel.num_levels to 15 (using hal-set-property IIRC), restarting g-p-m and then trying to change the brightness again please.

Hughsie,

Double check the current value:

# hal-get-property --udi '/org/freedesktop/Hal/devices/pmu_lcd' --key laptop_panel.num_levels
14

Set the num_levels to 15:

# hal-set-property --udi '/org/freedesktop/Hal/devices/pmu_lcd' --key laptop_panel.num_levels --int 15

Test the new value is set:

# hal-get-property --udi '/org/freedesktop/Hal/devices/pmu_lcd' --key laptop_panel.num_levels
15


That seemed to work fine. Now, when using gpm:

[gpm_brightness_init] gpm-brightness.c:207 (21:44:19):   Starting: (8 of 14)

.. and increasing the brightness to max:

[emit_button_pressed] gpm-hal-monitor.c:198 (21:45:13):  emitting button-pressed : brightnessup (1)
[hal_button_pressed_cb] gpm-power.c:1695 (21:45:13):     emitting button-pressed : brightnessup (1)
[power_button_pressed_cb] gpm-manager.c:1708 (21:45:13):         Button press event type=brightnessup state=1
[gpm_screensaver_poke] gpm-screensaver.c:390 (21:45:13):         Not poke'ing, as gnome-screensaver not running
[gpm_brightness_set_hw] gpm-brightness.c:299 (21:45:13):         Setting 14 of 14


If I try to go higher:

[emit_button_pressed] gpm-hal-monitor.c:198 (21:45:33):  emitting button-pressed : brightnessup (1)
[hal_button_pressed_cb] gpm-power.c:1695 (21:45:33):     emitting button-pressed : brightnessup (1)
[power_button_pressed_cb] gpm-manager.c:1708 (21:45:33):         Button press event type=brightnessup state=1
[gpm_screensaver_poke] gpm-screensaver.c:390 (21:45:33):         Not poke'ing, as gnome-screensaver not running
*** WARNING ***
[gpm_brightness_set_hw] gpm-brightness.c:295 (21:45:33):         set outside range (15 of 14)


So it seems like maybe that's the ticket. Does that mean that this is a HAL bug? Is HAL not correctly detecting the right number of brightness levels?

Also, unrelated to this bug: is there plans for gpm/hal/whatever to support things like ambient light sensors or my very funky backlit keyboard?

Yes, this is a hal bug, which I can see:

hald/linux2/pmu.c:      hal_device_property_set_int (d, "laptop_panel.num_levels", 14);

And for the abbient light level device, I think David Zeuthen is working on a HAL addon, and so any g-p-m checkbox can be trivially added.

Do you want to try fixing the hal bug (and send a patch to the hal mailing list) or do you want me to?

Well, the interesting thing is that the comment above that piece of code says:

   /*
    * We can set laptop_panel.num_levels as it will not change,
    * all powerbooks have 15 steps for brightness, where state 0
    * is backlight disable.
    */

So, if this were correct, shouldn't the backlight go out if I set the LCD brightness to 0? This definitely isn't happening.. so maybe that should be a bug as well in hal? What do you think?

Can you try looking in : /usr/share/hal/scripts/hal-system-lcd-set-brightness

There's a line:

hal-system-power-pmu setlcd $value

maybe try changing that to:

hal-system-power-pmu setlcd $((value - 1))
or
hal-system-power-pmu setlcd $((value + 1))

There's also the hal-system-lcd-get-brightness to modify if that works.

Richard.

Richard,

I managed to get the desired outcome by doing:

hal-set-property --udi '/org/freedesktop/Hal/devices/pmu_lcd' --key laptop_panel.num_levels --int 16

.. and then using your tip, setting value-1

if [ "$HAL_PROP_LAPTOP_PANEL_ACCESS_METHOD" = "pmu" ]; then
        hal-system-power-pmu setlcd $((value-1))

Now, I get full brightness when plugged into AC, and also the backlight turned off when I adjust it right down.

So, should a fix for this go into hal?

What about leaving the laptop_panel.num_levels at 15 (as this is logically correct, 1-15) and then just make the change $((value-1))? I can test this myself tonight when I get back to Rochester and I get my iBook to boot :-)

I don't think we should be able to turn the backlight off just by sliding the slider to the minimum, this isn't what users expect! :-)

Richard.

Sounds reasonable, although I do find it quite handy sometimes to be able to disable the backlight altogether. 

Also, one thing that I have found slightly annoying is that if you hold the brightness down button down, it doesn't continue dropping the brightness until you  do a repeat press. 

Can this be trivially added to gpm?

what does 'lshal -m' say when you hold down the button?

No difference between holding down the button as opposed to short presses.

Still only the 1 event:

usb_device_5ac_214_noserial_if0_logicaldev_input condition ButtonPressed = brightnessdown

Then, no sorry. g-p-m can only react to HAL dbus events. You could maybe try and find out why HAL doesn't repeat the event.

I've sent two patches to the HAL list that should fix the problems. I've cc'd you in both.

Richard.

Thanks Richard. Looks good. 

I've applied the fixed to HAL. You probably want your distro to pull in the HAL patch (i.e. create a distro bug) or just wait until 0.5.8 is released.

Thanks for your debugging efforts; it made the bug really easy to spot.

I'll try and get Gentoo guys to add it to the current release of HAL.

Thanks for your help Richard, in making GNOME on everything a great experience ;)

Thanks ;-)

HAL 0.5.8 should be out in the next few days if that helps.

R.