Fwd: Proposal for resolving powernowd/apmd vs. (k)powersave conflict

Michael Biebl biebl at teco.edu
Fri Mar 10 16:01:37 GMT 2006

Luka Renko wrote:
> On 3/10/06, Michael Biebl < biebl at teco.edu> wrote:
>> This approach has many problems and I would advise strongly against it.
> I understand and this is why I wanted to check how much such hack can be
> cosidered as valid workaround. I still see it as an option for myself (and
> whoever else) in case that klaptop stays for Dapper.
> If kubuntu decides to go with (k)powersave, kubuntu-desktop would simply
>> depend on kpowersave/powersaved instead of apmd/powernowd/klaptopdaemon.
>> Problem solved.
> We still have an issue with users that would have also
> ubuntu-desktop/edubuntu-desktop installed at the same time. But I agree with
> Achim that we should make first best KDE desktop, then think about for users
> that would install GNOME desktop in addition. When Kubuntu will work with

Our first priority should be, to get (k)powersave seamlessly integrated
into Kubuntu. Ubuntu won't swich to (k)powersave for Dapper anyways.
In addition IIRC kubuntu-desktop and ubuntu-desktop can't be installed
side by side.

> powersave, I plan to test also with ubuntu-desktop installed to see if there
> are any unwanted side-effects to gnome-power-manager. Actually I do not
> expect to many side effects fro GNOME.

Let's focus on Kubuntu for now. GNOME and g-p-m should be Dapper+1
(Although g-p-m should work with powersaved if it uses only the hal
callout scripts)

> For now, to give you a chance to easily test my packages I added a
>> Conflicts/Replaces/Provides: powernowd, apmd to powersaved and a
>> Conflicts/Replaces/Provides: klaptopdaemon to kpowersave.
>> This way kubuntu-desktop is not unistalled if you "apt-get install
>> kpowersave".
> Sounds good to me. Not sure what does this mean for kubuntu-desktop.
> Achim mentioned dpkg-divert - I did not have time to look into that (as I
> heard first time for it), but it may be something we want to consider.
> The more important problem is, how we handle the event processing done
>> by acpid. Right now, acpi-support installs a bunch of scripts in
>> /etc/acpi/. When an acpi event happens (e.g. a power button pressed
>> event), acpid calls the script defined in /etc/acpi/events/powerbtn
>> (/etc/acpi/powerbtn.sh). This is obviously not what we want, because
>> powersaved should be responsible for all event processing and apply the
>> correct rules and policies. acpid's sole purpose is to provide a socket
>> where several processes (powersaved, hald, Xorg) can listen on acpid
>> events.
> This is true, but if you look at these scripts, they check for existance of
> g-p-m, klaptop and kpowersave and do not process events if such daemons are
> active. What I think it is wrong is that they check for kpowersave (which is
> just GUI) and not for powersaved, which is actually doing the job.

Only for some of the scripts in /etc/acpi. Not all of them contain this
check (see also my comment on option 2 below).

> I am no expert here (just investigating Ubuntu power mgmt for 3 months ;-)),
> but acpid is there exactly for the purpose that events can be delivered to
> multiple listeners and it is up to them to coordinate between them.

Well, if powersaved is in charge of the power management, it is best to
let it handle all the acpi events. Take /etc/acpi/power.sh from
acpi-support: It collides with the set_disk_settings script from
powersaved (although it does not cause ill effects)

> I would also like to point out that at leaxst on my system (with
> 0.5.2kpowersave) I have not experienced any ill-effects that would be
> caused by
> existing acpi-support. However I am always in KDE, therefore cannot say what
> would happen on console if both acpi-support script and powersaved would do
> something about it.
> So we have three possibilities here (in decreasing order of my preference):
>> 1.) Install a diversion of /usr/sbin/acpid. Create a wrapper script for
>> acpid and filter the arguments passed to acpid. When acpid is called
>> with -c /etc/acpi/events replace it with -c /etc/acpi/event.ignore (an
>> empty directory installed by powersaved). This effectively and
>> efficiently disables the event processing of acpid. This is the approach
>> I have taken right now. Take a look at /usr/sbin/acpid after installing
>> powersaved.
>> I first tried to divert the /etc/init.d/acpid init script but this
>> failed because dpkg's config file handling comes into play at that moment.
>> 2.) Add a
>> if pidof powersaved; then
>>     exit 0
>> fi
>> stanza at the beginning of each script in /etc/acpi. This means we would
>> have to prepare new releases for acpid and acpi-support. In addition it
>> would be less efficient, because acpid would starts a shell for each
>> event to process and simply quits directly afterwards.
>> 3.) Provide a modified version of the acpid package for kubuntu (IIRC
>> this is not possible) which includes a modified init script.
>> I strongly prefer the first option.
> I think 2. is the way Ubuntu is going and I am not sure if we want to change
> this that late in the process. We will probably need to get in contact with
> maintainer of acpi-support and propose changes as required.

We could go with 2, but that means that we would have to modify
acpi-support, which requires additional work and new uploads, resulting
in even less time to test (k)powersave. The powersaved package as of now
wouldn't require changes for acpi-support, that's why I prefer this
For Dapper+1 we could tackle this issue properly and try to provide a
common script library that both acpi-support and powersaved could use.
Maybe we can convince the acpi-support and powersaved devs to avoid
duplication of work. But this is definitely not an option for Dapper.


Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20060310/ab69bade/signature.pgp

More information about the kubuntu-devel mailing list