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

Luka Renko 74.luka at gmail.com
Fri Mar 10 05:00:36 GMT 2006


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

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.
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.
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.
Also, these scripts are not called that often that I would be overly
concerned about efficiency.

I prepared packages and uploaded it to my private repo.
> Add the following to /etc/apt/sources.list
>
> deb http://www.teco.edu/~biebl/ubuntu/<http://www.teco.edu/%7Ebiebl/ubuntu/>dapper main
> deb-src http://www.teco.edu/~biebl/ubuntu/<http://www.teco.edu/%7Ebiebl/ubuntu/>dapper main


I am currently at the airport to board the plane to CeBit. I will for sure
test this, but not before Saturday evening.

@Jonathan: Is there a realistic chance that these packages make it into
> Dapper or is too late for the feature freeze?
> @Achim,Luka: Please start the procedure to get these packages into the
> Dapper archive. I'm not familiar with the (K)ubuntu procedures so I
> wanted to pass this task on to you or at least give me assistance. IIRC
> Jonathan talked about a laptop testing group in ubuntu where we should
> send these packages too, how would we do that.


I am also new here,  but I am sure there will be MOTUs that will help us
with this process if we prove it works and have clear benefits.

Let's get as much testing quickly as possible and then Jonathan can
> decide if (k)powersave should be used as the default power management
> solution for Kubuntu 6.04


Thank you for your work and helping us make Kubuntu power management better!


Regards,
Luka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20060310/8d910455/attachment-0001.htm


More information about the kubuntu-devel mailing list