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

[Timo Hoenig]

Hi,

On Thu, 2005-08-04 at 10:25 -0400, David Zeuthen wrote:

[...]

> On Tue, 2005-08-02 at 23:14 +0200, Timo Hoenig wrote:

[...]
 
> > I have a several systems which work fine (= you can adjust the screen
> > brightness) with the generic video driver.
> 
> Out of curiosity is it possible to detect for which systems this work in
> a robust manner? Or do you need to key off things in e.g. the SMBIOS
> (dmidecode)

I haven't investigated that, yet.  Until now I just can confirm that
everything is very unreliable.  Results for those systems (IBM,
Fujitsu-Siemens, Acer, Toshiba and some others) I've tested:

      * video.ko loads on every system
      * the first sub-directory of  /acpi/video  already differs for
        many systems (sometimes its VGA, sometimes GFX0, looks like a
        key which is read from the system's DSDT)
      * even if  /proc/acpi/video/$DIR/LCD/brightness  pretends to show
        the available brightness levels it
              * does not mean that these brightness levels can be used
              * does not mean that changing brightness is working at all

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.

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

> > > I know that the
> > > latest experimental version of ibm-acpi supports this and I've got a T41
> > > so I can do that actually =).
> > 
> > Supports what?
> 
> ibm-acpi 0.11 with experimental=1
> 
> [root at daxter acpi]# cat /proc/acpi/ibm/brightness
> level:          7
> commands:       up, down
> commands:       level <level> (<level> is 0-7)

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").

[...]

> >       * void SetBrightness(int)
> > 
> >         Either we take
> >         
> >               * absolute values (usually about eight to 15 brightness
> >                 levels are available)
> >         or
> >         
> >               * relative values (map absolute levels to 0 to 100)
> > 
> >         I vote for the latter to ease the development of applications
> >         which use this interface.
> 
> Will, I'd go for the absolute actually but I'm not too attached to it.
> Should also just require to export properties a'la
> 
>  laptop_screen.brightness_num_steps = 8
> 
> to convey the fact that SetBrightness(int value) can take
> value=0,1,2,...,7. In addition we could have 
> 
>  int SetBrightnessPercentage(int percentage)
> 
> I'd suggest to do that.

Sounds good.  Just a note:  Some systems I've touched showed percentages
only using the generic ACPI video driver:

        [thoenig:/proc/acpi/video/VGA/LCD]$ cat brightness
        levels:  100 40 0 40 100
        current: 0

> >       * int GetBrightness(void)
> > 
> >         Same as above. Either return absolute or relative values
> 
> 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.

> >       * void IncreaseBrightness(void)
> >         
> >         Increase by one brightness level depending on the given system.
> >         
> >       * void DecreaseBrightness(void)
> > 
> >         Decrease by one brightness level depending on the given system.
> > 
> > I've recently wrote code for these things which should be pretty easy to
> > integrate into HAL once we agree about the design of the interface.
> 
> Sounds good though I'd think these would just be simple shell-scripts,
> e.g. we'd distribute
> 
>   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.

But I also have no strong objections against some shell script magic.

> and just match in .fdi files on certain properties (we would need to put
> some property like system.linux.acpi_extras=ibm|toshiba etcc) to select
> the right ones? This would be dead-simple I think...

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.

> The way I'd do this is to put all this in the hal spec, specifically
> 
>  - what properties do we export
>  - what interfaces/methods do we export (plus what exceptions)

Fine.

> Also worhtwhile thinking whether it should be laptop-screen specific or
> whether we should be even more generic and just call it a Monitor (and
> in the future make this work (via X.org/dri/fbdev drivers) for generic
> display monitors too. My hunch feeling is that we should just make it
> laptop-screen specific....

What about a device object as child to the Computer object?

+ Computer
|
+--+ Monitor
|  |
|  +- CRT
|
+--+ Monitor
|  |
|  +-+ LCD
|    +- {method/properties}
|     
+--+ USB
|
. 


> > A decent design for *very* system specific interface would be cool, too.
> > Think of:
> > 
> >       * keyboard light on the top of the screen of many IBM laptops
> >       * funky LEDs on ASUS laptops
> >       * any other function provided by the system specific ACPI drivers
> 
> This could be interesting too but I think the LCD brightness is a good
> place to start?

Totally agreed, just wanted to note that there are some more gaps
between kernel and user space regarding laptops which could and should
be filled by HAL.

> Cheers,
> David

See you,

   Timo

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