What's X doing with the acpi event interface? We need acpid as multiplexer for powersave, hal and ial. We came to an agreement with the maintainers of those applications that no application will 'catch' the event interface itself and everybody has to use acpid as multiplexer.

This is IMO a race and a result of new code in the X-server:

==========================================
2005-08-22 Alan Hourihane <alanh@fairlite.demon.co.uk>
        * programs/Xserver/hw/xfree86/os-support/linux/lnx_acpi.c
        * programs/Xserver/hw/xfree86/os-support/linux/lnx_apm.c
        * programs/Xserver/hw/xfree86/os-support/linux/Imakefile
        Add basic ACPI Linux support so that events can be passed to the driver.
        (Alan Hourihane)

2005-10-31  Kevin E. Martin  <kem-at-freedesktop-dot-org>

        * programs/Xserver/hw/xfree86/os-support/linux/lnx_acpi.c:
        (lnxACPIOpen), (lnxCloseACPI):
        Fix fd leak by closing them in the ACPI code instead of just using
        shutdown
==========================================

This need to be fixed. The X-Server never should try (as all other programms) to accec the kernel acpi interface directly. I acpid not available, retry to connect later in a loop.

*** Bug 131506 has been marked as a duplicate of this bug. ***

How do you plan to fix this?

I need to discuss this will Egbert/Matthias next week, since both are absent tomorrow.

BTW, it's an already knwon problem.

https://bugs.freedesktop.org/show_bug.cgi?id=4718
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169766

Created attachment 57714 [details]
disables ACPI code

I'll disable ACPI code for now.

Use

  Option "NoPM" "on"

in 'Section "ServerLayout"' of /etc/X11/xorg.conf as workaround for now. But this disables APM as well!

Could someone please check that the new Xserver no longer touches /proc/acpi/event?

/work/built/mbuild/shannon-sndirsch-6/i386/xorg-x11-server-6.9rc2-4.i586.rpm
/work/built/mbuild/shannon-sndirsch-6/x86_64/xorg-x11-server-6.9rc2-4.x86_64.rpm

Sorry, I accidently removed the mbuild builds, but it's already in STABLE, so simply use the RPMs from STABLE.

Ok, will test today.

Tested on two machines, after various boots everytime everything worked as expected. So I say - fixed.

Sorry, but this is a workaround by disabling new ACPI code completely.

Is there any sample code available for using acpid?

Have a look at 

./hald/linux2/addons/addon-acpi.c

of HAL.

Thanks. Looks like the code already exists, but the Xserver uses the acpi event interface, because acpid is not running yet.

[...]
    if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) > -1) {
        memset(&addr, 0, sizeof(addr));
        addr.sun_family = AF_UNIX;
        strcpy(addr.sun_path, ACPI_SOCKET);
        if ((r = connect(fd, (struct sockaddr*)&addr, sizeof(addr))) == -1) {
            shutdown(fd, 2);
            close(fd);
            fd = -1;
        }
    }

    /* acpid's socket isn't available, so try going direct */
    if (fd == -1) {
        if ((fd = open(ACPI_EVENTS, O_RDONLY)) < 0) {
            xf86MsgVerb(X_WARNING,3,"Open ACPI failed (%s) (%s)\n", ACPI_EVENTS,
                strerror(errno));
            return NULL;
        }
    }
[...]

Couldn't we make sure that acpid is started before the Xserver?

Yes. For 10.1 we really should push acpid and friends (hal) to the front of our boot process.  We have some orphan (?) dependency on $remote_fs in the acpid start script.

(In reply to comment #16)
> Thanks. Looks like the code already exists, but the Xserver uses the acpi event interface, because acpid is not running yet.

Could you please consider removing the fallback?  All of our packages depending on acpi events have agreed not to fall back and hence not to access the kernel interface directly.

For situations where acpid gets restarted (update, manual restart) it might be sane to poll for the acpid socket until its back.

> Could you please consider removing the fallback?  All of our packages 
> depending on acpi events have agreed not to fall back and hence not to 
> access >the kernel interface directly.

I'll do so.

> Yes. For 10.1 we really should push acpid and friends (hal) to the front of > our boot process.  We have some orphan (?) dependency on $remote_fs in the 
> acpid start script.

Coolo should know best, which init script this exactly is. Probably xdm and earlygdm/earlykdm !?! Coolo?

Meanwhile I dropped 'should-start $remote_fs' from rcacpid and submitted an updated acpid package.

That acpid package is broken then. acpid is in /usr - as such in $remote_fs 

earlygdm/earlykdm need a should-start acpid then I guess, but only if acpid can be really started early and from /

I don't see any reason why this should not work.

because /usr/ might not be available before network is up.

Am i allowed to install acpid to /sbin/? If yes, we can solve this properly.

Beware that acpid will need syslog in the not-too-distant future, though.

New xorg-x11 package submitted.

Tue Nov 22 15:15:07 CET 2005 - sndirsch@suse.de
- ps_acpi.diff (obsoletes p_disable-acpi.diff):
  * disable fallback to proc acpi event interface (#133440)

Assigning to coolo to adjust earlykdm. Needs to be reassigned to gnome-maintainers@suse.de to adjust earlygdm afterwards.

#23: acpid will have to attach syslog when it's ready then. I won't accept an init script that relies on syslog and is before X startup.

I will look at fixing the ACPI code in X.
Please reassing to me once other issues got ironed out.

Egbert, what do you want to fix in ACPI code exactly? Is it supposed to be broken?

The bugreport is about accessing the proc acpi event interface directly instead of using acpid. I fixed this by removing this fallback, which is our policy. The problem is, that the Xserver is started before acpid. This needs to be fixed by the KDM and Gnome maintainers in earlygdm/earlykdm init scripts.

i also fixed the acpid package to no longer need $remote_fs, so it should start pretty early, almost before everything else, so this is no longer really urgent, just check that it does not fall back to /proc/acpi/event if acpid ist restarted but instead reconnects to the socket.

I think we can close this now.