Re: [gpm] Support for brightness_in_hardware hal property

[Richard Hughes <hughsient gmail com>]

On Tue, 2008-06-24 at 18:05 +0200, Tomaž Šolc wrote:
> > Right, I guess the gpm_brightness_xrandr_X commands are not setting
> > hw_changed properly.
> 
> I thought widget is displayed when the "brightness-changed" signal is 
> emited (like in gpm_brightness_xrandr_may_have_changed() ).
> 
> I don't see any function that would emit this signal in 
> gpm_brightness_hal_*.

Right, in the xrandr code it's just set to this, so it's never fired
either:

	if (FALSE) {
		gpm_brightness_xrandr_may_have_changed (brightness);
	}

I'm waiting for xrandr to send a "brightness changed" signal, but this
means implementing some code in the X server and I'm waiting for someone
else to fix it :-)

We probably need to hook this up in the HAL code, but HAL doesn't seem
to emit this either for me. This is all a mess -- I guess from 2.25 I'll
only support the xrandr way of doing things and then we'll just have to
fix the drivers.

> Hm. It looks like gpm_brightness_xrandr_output_get_internal() doesn't 
> detect that the hardware has changed the brightness.
> 
> If I disable gpm_brightness_xrandr_output_set_internal(), then 
> output_get always returns the same value, regardless of the actual state 
> of the backlight.
> 
> So even if you use hal attribute, you can't get the real brightness 
> level through xrandr.

Right, so this sounds like a X bug. When we do a query brightness, we
should always check the hardware and not use a cached value. Can you
open a bug against the X driver you are using please?

> There is an added complication that on Eee you can't know which 
> brightness button was pressed (up or down - on mine both buttons behave 
> as BrightnessDown). I heard that some other Asus laptops also behave 
> like this.

Sure, but if we can read the backlight after we get the button press,
then it's trivial to reverse the logic if it's the "other way".

Thanks,

Richard.