[PATCH] command line options for hald-addon-acpi

[David Zeuthen]

On Thu, 2005-08-04 at 17:31 +0200, Timo Hoenig wrote:
> To make it short:  No, I am not aware of a robust way for a reliable
> auto detection whether a system supports changing the brightness or not.

Oh, OK, that was what I was afraid of...

> It's easier for the specific drivers:  If they load, they most likely
> support what they are exporting via /proc/acpi/$VENDOR .

Yup - I think this is the only reliable way at the moment.

> Yepp.  Just a short note:  Having the brightness control in HAL is most
> interesting for systems on which the LCD brightness can not be
> controlled via hotkeys (e.g. Toshiba).  For other systems it is still
> interesting regarding power schemes ("when I'm running on batteries I
> want to switch down to 600 MHz and have my LCD running with
> semi-brightness").

The main use, I think, is for e.g. gnome-power-manager or something else
in the desktop session to dim down the LCD when switching to battery
power yes.

> > and GetBrightnessPercentage() ? Probably we could do without both
> > methods and just export properties?
> 
> Why would you suggest using properties?
> 
> HAL won't need the knowledge about the current brightness level all the
> time.  Only at the time, a client actually wants to know the current
> brightness.  Polling like batteries doesn't sound necessary, too, since
> we do not really care if the LCD brightness is changing due to some
> other process/user interaction or BIOS action.

That's a pretty good point actually =). So I suppose that
GetBrightness() is the way to =)

> >   ibm-acpi-set-brightness.sh
> >   ibm-acpi-get-brightness.sh
> >   toshiba-acpi-set-brightness.sh
> >   toshiba-acpi-get-brightness.sh
> >   generic-acpi-set-brightness.sh
> >   generic-acpi-get-brightness.sh
> 
> I'd prefer having those functions as code since the interfaces of the
> kernel modules are very unlikely to change. Having some simple open,
> read and write syscalls is just more efficient.

Sounds good to me actually.

> Yes, we'd just to make sure that the relevant modules were probed before
> HAL is initializing.  Once this is done its easy to
> scan /proc/acpi/$VENDOR and its subkeys for the available functions.

Yup, we want to do this when populating the root computer device object
in hald/linux2/osspec.c I guess.

> What about a device object as child to the Computer object?
> 
> + Computer
> |
> +--+ Monitor
> |  |
> |  +- CRT
> |
> +--+ Monitor
> |  |
> |  +-+ LCD
> |    +- {method/properties}
> |     
> +--+ USB
> |

I'm not really sure. I think, long term, we want to interact with the
either 1) the mode-setting daemon that X.org is talking about; and/or 2)
sysfs objects exported by the fbdev drivers in the kernel. Plus, since
we group hardware according to parent/child relationships it should
probably look like this

 Computer
  |
  +- Graphics card
     |
     +- CRT Monitor
     |
     +- DVI Monitor
     |
     +- Laptop Panel

where each of the monitor objects expose basically the same interface
more or less (ok, CRT monitors may not expose the SetBrightness
interface). But all this is just guess-work from my side - we really
need to know what we can expect from the kernel/X.org... Hence why I
want to keep it simple initially...

Cheers,
David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal