LaptopMode

[Richard Hughes]

On Thu, 2005-09-15 at 21:27 +0200, Danny Kukawka wrote:
> On Thursday 15 September 2005 17:59, Richard Hughes wrote:
> > > Not sure if this is a good idea in conjunction with smbios.chassis.type
> > > because this key is not a really reliable information about the system
> > > type.
> >
> > What about checking for battery.type == primary? That's only laptops I
> > guess - or not checking at all, and let the program (i.e. g-p-m) do the
> > filtering.
> 
> Maybe, but not complete sure.
> 
> > > Laptop mode on its own is not very usefull. You have to adjust the rest
> > > of your system, too (e.g. by using the laptop-mode script).
> >
> > Yes, but there is *lots* of extra stuff in the laptop-mode script.
> > re-mounting disks, setting hdd spindowns, and lots of kernel foo.
> 
> Yes, but I don't understand, why you would implement this in HAL. Why do we 
> need this e.g. on a desktop system or on a server (e.g. s390/s390x). 

Well, calling SetLowPowerMode doesn't make much sense on a
desktop/server anyway.

> > Spindowns have already been discussed, and remounting disks seems a bit
> > drastic.
> >
> > I wanted to concentrate on the kernel-foo.
> 
> This is the problem. If you implement this in HAL, it's IMO a little  
> maintainance nightmare.

Why? The laptop-mode scripts don't change all that often...

>  On one site you need this only on laptops (and not 
> all user and distibutions want this)

Then they can *easy* patch out the relevant part of the fdi file (but
see below).

>  on the other you must permanently check 
> for each new kernel if there is something changed in the kernel parameter.

Hmm. Not sure how often these are realistically change - HAL already
depends on a newish kernel.

> > Shouldn't we just get some sane default values for these sorted out (the
> > ones laptop-mode seem sane), and then let all this be transparent to the
> > user?
> >
> > Adding this little bit of code lets us to do the kernel cleverness,
> > without packaging the laptop-mode scripts, and having hal depend on
> > them.
> 
> But what about add this to special script on your distro or to a special 
> little daemon only for such distro and maybe also desktopenviroment specific 
> things? We implemented this for example already (at SUSE and ALTLinux) to the 
> powersave daemon which do this and all other powersave issues for us (now 
> with D-BUS support, too).

Sure, but that means installing and maintaining a whole other service,
just to set a few kernel parameters.

What's the difference between setting the kernel parameters in PowerSave
or HAL? 

We can add conditionals (like we did in the suspend scripts) to detect
SUSE or ALTLinux, and use PowerSave to set the kernel parameters if you
wish - else we can just do the kernel foo in HAL for all the other
people not using PowerSave.

Richard.