Bug#347680: Xorg breaks acpid
Marcus's analysis looks right to me:
> > But who can tell which is the grand-piece-of-sw that has the exclusive
> > right to open /proc/acpi/event?
> The one which has been designed to multiplex the events to make them
> available to other programs, and it's acpid.
The standard Debian setup is to use acpid to multiplex the event stream.
Even if it is possible to run with acpid, that should be a different,
non-standard option.
There are lots of reasons to multiplex in userspace instead of in the
kernel. Among these is that a userspace multiplexer can filter and
modify the stream as it goes by, and a userspace multiplexer can pull
events from multiple sources including virtual events injected by other
sources than the raw hardware. The earlier comments that obviously the
kernel should multiplex just aren't right. Doing it in userspace makes
sense, and if it is done in userspace, then additionally doing it in the
kernel would be a bad thing.
At any rate, the current strategy isn't right. If the system is using
acpid--the most common configuration--then it is a bug for X to get in
the way of acpid.
It is laudable that Xorg currently tries to support ACPI even when acpid
is not running. However, this is an unusual and only marginally useful
configuration, isn't it? Thus, if nothing else, it would seem to make
sense to simply remove the non-acpid ACPI support when compiling for
Debian. In that case, the party line would be, if you want to use ACPI,
then you install acpid and programs talk to that.
If it is still desirable to make X work without acpid around, then that
should surely be a non-standard configuration which requires an
*explicit* configuration option on the X server. This does not appear
worthwhile for Debian, since we do have acpid easily installable, but
maybe it is sufficiently worthwhile for other Linux distributions that
it is worth including.
-Lex
Reply to: