Bug 169766 - New xorg steals /proc/acpi/events
New xorg steals /proc/acpi/events
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: acpid (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-03 09:29 EDT by Pierre Ossman
Modified: 2014-03-16 22:56 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-07 07:04:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 4718 None None None Never

  None (edit)
Description Pierre Ossman 2005-10-03 09:29:26 EDT
New versions of xorg has better integration with ACPI. As a part of this it
tries to communicate with either /proc/acpi/events or acpid. Since rhgb is
started before acpid the X server till open /proc/acpi/events causing acpid to fail.

acpid probably needs to be better integrated with initscripts so that it's
started before rhgb.
Comment 1 Bill Nottingham 2005-10-03 13:59:11 EDT
acpid actually will probably go away soon.

Ideally, ACPI events are exported over something that allows multiple listeners.

So, some questions:

1) What is X actually using ACPI lisetening for?
2) Could that be routed through HAL, either via gnome-power-manager, or a
system-level generic power daemon?
3) Can the kernel be fixed to allow multiple listeners?
Comment 2 Richard Hughes 2005-10-03 14:05:58 EDT
All acpi events can go through HAL. HAL should use /proc/acpi/events and
everything else should use HAL for the listener (in my opinion).

What *exactly* is it listening for? The only thing I get from this is my laptop
buttons, cpu step, and battery state.

Sounds like xorg is getting a bit big for it's boots...

Richard.
Comment 3 Mike A. Harris 2005-10-03 16:02:07 EDT
Presumeably this is Xorg CVS head you are referring to.  Please clarify.

I've followed up on the email thread on xorg list too.

<4340F683.4030708@drzeus.cx>
Comment 4 Mike A. Harris 2005-10-03 16:06:41 EDT
notting:

Oh, by the way, the bug report is very vague.  This only happens when
rhgb is being used.  (Yay, another reason to ditch rhgb!)

The X server starts first, tries to talk to acpid, and if it isn't running
(which it wont be when rhgb starts the X server), it tries to use
/proc/acpi/events itself.  Then the X server is started, and acpid can't
start.

I have to personal thoughts on this:

1) The X server should have a config file option to disable acpi completely,
   and also to just disable the fallback.  Actually, IMHO the fallback should
   be off by default, and require a config file option to enable.


This is something that should be filed in X.Org bugzilla though IMHO, not
Red Hat bugzilla.

Comment 5 Pierre Ossman 2005-10-07 06:26:13 EDT
Ehm... strange... Bugzilla seems to have swallowed my reply here.

To clarify, yes this is xorg CVS. And yes, it only happens when rhgb is used.
Comment 6 Mike A. Harris 2005-10-07 07:04:15 EDT
Please file a bug report in X.Org bugzilla against CVS head version,
indicating that the X server should only default to using ACPI if
acpid is running, and should not attach to the ACPI device directly
if it is not.  To be clear, this is an X.Org bug, not a Red Hat one.
Comment 7 Richard Hughes 2005-10-07 08:04:48 EDT
Does anyone know what xorg *does* with the acpid events?
Comment 8 Pierre Ossman 2005-10-07 10:16:38 EDT
And they consider it a bug that acpid is started after X. So they'll just tell
me to file a bug here. This has to be solved through discussion between you and
X.org.
Comment 9 Mike A. Harris 2005-10-07 11:38:10 EDT
Once you file your bug report at X.org, paste the URL here, and we will
track the issue in X.Org bugzilla, and engage in communication with
X.Org as always.

It is not a bug that acpid is started after X, it is intentional, and I
can assure you that X.Org will see it as a bug also.  The important
thing is for you to actually report it to them first, so that things
can happen, or it may fall between the cracks and not get fixed for
X11R7.

Note You need to log in before you can comment on or make changes to this bug.