[hal-info] Dell laptops control brightness in hardware

Rui Tiago Matos tiagomatos at gmail.com
Thu Nov 15 13:11:31 PST 2007


On 15/11/2007, Danny Kukawka <danny.kukawka at web.de> wrote:
> And this is why you need "brightness_in_hardware=true" to tell the userspace
> software to not react on these keyevents because the brightness get set
> directly by the keys in the hardware. Currently it isn't a problem since you
> don't get these events.

This is how fedora 8 hal reports it:
$ lshal | grep in_hardware
  laptop_panel.brightness_in_hardware = false  (bool)

And I seem to get the events:
$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
20:58:35.429: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = brightness-down
20:58:40.367: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = brightness-up

The problem is that I only get these events *once*, the fisrt time
(since last reboot) that I hit Fn+Up or Fn+Down. Any subsequent
Fn+Up/Down do change the brightness (since its set in hardware/BIOS)
but hal does not get the events.

> The question is: do we really need the events get send to HAL if the change is
> done in hardware?

I think we do need them. Else how can e.g. gnome-power-manager know
how much brightness there is after it sets the value initially and
then the user changes it via the keys? I mean, there should be a level
on the software stack that always knows how much brightness is set on
the hardware, or else, the GUI always has to ask the hardware whenever
it wants to display a value to the user.

So, IMHO, the question is: what level on the stack always knows the
current brightness level? And we should keep in mind
fast-user-switching too.

Rui


More information about the hal mailing list