ACPI integration

Mike A. Harris mharris at mharris.ca
Mon Oct 3 13:01:30 PDT 2005


Alan Hourihane wrote:
> On Mon, 2005-10-03 at 11:14 +0200, Pierre Ossman wrote:
> 
>>New versions of xorg seem to have better integration with ACPI by
>>talking to either acpid or directly with the kernel. On fedora this
>>causes problems.
>>
>>Since fedora uses a graphical boot, the X server will have opened
>>/proc/acpi/events, causing the startup of acpid to fail. For some reason
>>it is only opened during the graphical boot, not by the "normal" X
>>server. So I'm guessing there's a way to control this behaviour.
> 
> 
> ACPID needs to be running before the Xserver starts. 
> 
> The Xserver will try to open /var/run/acpid.socket which is what acpid
> provides when it's started. If the Xserver can't open it, then it will
> open /proc/acpi/events directly which causes acpid to fail.
> 
> So really, acpid should be moved up in Fedora boot process.

Red Hat Graphical boot starts the X server immediately after
init, so that the boot process can proceed graphically.  That
is an intentional design of rhgb itself.

I personally do not favour our current rhgb's implementation
via using X as it has a lot of undesired side effects, but we're
stuck with it for now.

Is there a way of disabling the X server from touching
/proc/acpi/events via xorg.conf?  I haven't looked, but if not
perhaps one should be added and/or a --noacpi commandline switch.

We had a similar problem with DRI, wherein the first X server
started by rhgb would open the DRI device, and the second X
server would be unable to open DRI, as the first server was
running still when the second one was started by rhgb.

rhgb can use a custom config file, so it's possible to configure
its server invocation differently than the primary server to
work around this problem, if the X server can do it already.



More information about the xorg mailing list