[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: disappointment over default acpid config



On Sun, 2005-12-04 at 00:13 -0600, Callum Lerwick wrote:
> There's something seriously wrong with the current design of g-p-m, yes.
> I have it set to suspend-to-disk my laptop when I hit the power button.
> I noticed when I'm not logged in, at the GDM login screen, it doesn't
> work. This is silly.

I know, It's being fixed. Please create a bugzilla and we can discuss
the details there:
http://www.gnome.org/projects/gnome-power-manager/bugs.html

> Also, me and my wife share the laptop using GDM's
> flexible servers. What happens when two people are logged in? Three?
> Who's policy should be followed? 

Who ever is logged in at the moment. You can change this
in /etc/dbus-1/system.d/hal.conf, and if no-one is logged in, then the
policy of root.

> Who gets to enforce policy?

Anyone who can use org.freedesktop.Hal.Device.SystemPowerManagement can
issue methods to HAL, and anyone can try to store policy.

> What needs to happen is a setup much like NetworkManager, there needs to
> be a PowerManager daemon that talks to HAL and carries out policy, and
> has nothing to do with X or Gnome.

Nope, been down this route, please see the archives:
http://sourceforge.net/mailarchive/forum.php?forum=gnome-power-devel

> gnome-power-manager seems to be muddling three things: 
> 
> 1) configuring policy
> 2) carrying out policy
> 3) providing misc UI
> 
> Number 1 should be handled by a system-config-power applet. Power
> management is screaming system-wide to me. Per-user seems ugly and
> wrong. I see little reason to have per-user configuration. (I guess this
> is mostly what gnome-power-preferences is currently doing?)

Please see the g-p-m archives, this has been extensively discussed.

> Number 2 should be handled by a PowerManager daemon. Or hell, maybe just
> merge it all into the next generation init. (I already bitched about
> this earlier, and pm-scripts seems to be turning into yet another
> re-invention of what init/initscripts should be doing)

I don't think we need any more init states.

> Number 3 needs to just get blended into gnome. GUI options to suspend
> and hibernate should just be put right next to where you see "shut down"
> and "restart".

Ohh I hope so too! Again, create a bugzilla for the (what component
would be the logout window?), tell me the bugzilla number, and I can
offer some sample code to integrate it with Hibernate and Suspend
methods in HAL. We already know if the computer is able to suspend or
hibernate (well, if support is compiled into the kernel, and that's no
guarantee it's going to work...) and can trivially call a
suspend_to_disk or suspend_to_ram with one dbus call.

> And there's already a bazillion and one battery status
> applets. (Though I suppose g-p-m talks to HAL exclusively?

No, g-p-m can work with lots of other stuff talking to hal at the same
time.

>  Its also fairly pretty. 

Thanks!

> Does it need to be a notification area applet? Once the
> policy enaction is torn out, can't it be made a native gnome applet? Let
> the KDE guys write their own HAL based battery applet.)

I'm sure the KDE guys can easily use the information and methods in HAL
to improve the existing KDE pm-framework. I'm more than keen on this to
happen. GNOME Applets do not do what I need at the moment, (see
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174160 ) so until
then we should use a notification icon.

Richard.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]