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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]