On Thu, Feb 19, 2009 at 10:46:52AM +0100, Bart Samwel wrote:
> Leo L. Schwab wrote:
> > Correct. Since /proc/acpi/event has been deprecated since at least
> > 2.6.24, 'acpid' just plain won't work. Ergo, acpi-support won't work, and
> > neither will anything that plugs into that framework. [ ... ]
>
> Fair enough. :-) Thanks for explaining, I wasn't aware that this stuff
> was going away so soon.
It's actually been going away since 2.6.23 (I just looked at the
Kconfig).
To be completely fair, enabling /proc/acpi/event is a kernel option
(CONFIG_ACPI_PROC_EVENT). It is expressly marked as deprecated in the
Kconfig, but most distros seem to be turning it on, anyway, because the
userspace tools have been moving very slowly. And the userspace tools have
been moving very slowly because the deprecated behavior is still turned on.
I compile my own kernel, and forced the issue on my box, which is
why I notice this stuff.
> I'm just wondering about how I'm going to
> prevent *double* calls to laptop-mode-tools here -- or perhaps it just
> doesn't matter if I add locking so that simultaneous calls don't bite
> eachother.
>
I've already noticed this fight going on, which is one of the
reasons I uninstalled acpid entirely. Without looking at it in detail, I
think the packages acpid and/or acpi-support may need to be marked as
conflicting with pm-utils, since they both process the same class of events,
and both are written expecting to be the exclusive processor thereof.
In the case of laptop_mode, it seems to avoid doing redundant work
by keeping track of its current state, so I would expect it could be invoked
any number of times without clobbering things.
Schwab
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
