---------- Forwarded Message ---------- Subject: Fwd: Proposal for resolving powernowd/apmd vs. (k)powersave conflict Date: Friday 10 March 2006 06:00 From: "Luka Renko" <[EMAIL PROTECTED]> To: "Kubuntu Developer Discussion" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]
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 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/>dap >per main deb-src > http://www.teco.edu/~biebl/ubuntu/<http://www.teco.edu/%7Ebiebl/ubuntu/>dap >per 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 ------------------------------------------------------- _______________________________________________ powersave-devel mailing list [email protected] http://forge.novell.com/mailman/listinfo/powersave-devel
