---------- Forwarded Message ---------- Subject: Re: Fwd: Proposal for resolving powernowd/apmd vs. (k)powersave conflict Date: Friday 10 March 2006 17:01 From: Michael Biebl <[EMAIL PROTECTED]> To: Kubuntu Developer Discussion <[EMAIL PROTECTED]>
Luka Renko wrote: > On 3/10/06, Michael Biebl < [EMAIL PROTECTED]> 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 solution. 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. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ------------------------------------------------------- _______________________________________________ powersave-devel mailing list [email protected] http://forge.novell.com/mailman/listinfo/powersave-devel
