Bug 135071

DBus has been in xinitrc since August:

* Wed Aug 25 2004 Colin Walters <walters> 4.0.3-1
- Add DBus session to Xsession, xinitrc

All it does is start dbus, set an enviornment variable so apps can
find the session bus and then spawns the session.

CC'ing Mike Harris on this.  Mike, you made the latest changes in
xinitrc.  Can you think of a reason Mickey might be seeing this?

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

Mickey and Scott can you take the DBUS stuff out of the xinitrc and
see if things speed up?  If not then it could be other issues.

John P,

I removed the DBUS references from xinitrc (new vers), and it speeds
things up to "normal". I'm sure you know best when dbus went into
xinitrc, but perhaps its something to do with how dbus itself is
working. I recall also updating dbus so its a somewhat uncontrolled
environment here. The only thing I'm sure of is that all yum installed
packages on my box are up to date insofar as rawhide (dev tree) goes. 

When I diff xinitrc (new) with xinitrc from the prior package, I only
see the DBUS parameter on the start line in the newer package,
although there's other references to DBUS in both. I'd attach them
(and will if requested) but I suppose this is something you've already
checked out and have access too as well. 

By the way: Does it make sense to have two simultaneous processes (the
DBUS + Xclients & the ssh-* + Xclients ) running? This is what happens
with the latest version and is easily seen in the latest copy of
xinitrc. I can only recall ever seeing one before this (the ssh one).

Thanks, 

Mick

They are needed just to set the eviornment variables for the entire
session.  Can you post the diff from your two versions.  I just want
to check them against mine.  Last changes I made to dbus were to NULL
out some variables when freed and to change the dbus activation code
to look in /usr/shared instead of /usr/lib.

Created attachment 104946 [details]
diff between old version (first) and current version of xinintrc

One other note is that I needed to change the following line to include the
path:

----
# Xsession and xinitrc scripts which has been factored out to avoid duplication

. /etc/X11/xinit/xinitrc-common
---

because it failed to find the *common file. Without changing it I couldn't run
startx and have X run without an error.

Mick

I have tried to duplicate what you are seeing and glxgears seems to
run at the same speed with or without dbus in the session.  

By closing this are you saying that it is ok for GL screensavers to be
running at 1.7 frames per second, or that you do not see them running
slowly?

Honestly, I did not try to duplicate Mick's results, 'cause I was a
bit lost in what he was saying he changed, so do I need to file
another bug? perhaps this is an xorg problem with the GL mesa libs?

Scott:  I can't speak for John, but most likely he attempted to
reproduce it and wasn't able to,  and meant to close the bug
as WORKSFORME but chose NOTABUG by accident.  That's just a
personal assumption though.

I think what you are encountering here is not an xinitrc nor
dbus bug but rather an rhgb bug.  rhgb starts up an X server
for graphical boot, and then it starts up a second X server
which is the real X server.  The problem is, in the past this
was done sequentially and things "just worked", but now in order
to eliminate the 1-5 second flicker to text mode and back between
the 2 X servers, rhgb starts the second server and waits for
it to start up before switching.  This causes 2 X servers to
both be running simultaneously.

Because of this, the first X server gets DRI support, but the
second one gets no DRI support because only one X server can
have DRI if multiple servers are running.

The result of this, is that users essentially lose 3D acceleration
in rawhide right now.  We are currently exploring how to fix this,
but for now, users can simply disable rhgb by doing:

rpm -e rhgb

or modifying their grub.conf

Hope this helps.

That was it!
You know I don't have any idea why I ever use rhgb, I always select to
show details... Maybe just to see what it's breaking.

Thanks mike

For the record, I can't remeber closing the bug, just posting a quick
comment.  Sorry for that but it looks like it got resolved.  Thanks.

Sorry, I was away for work, not paying attention here, but while I
could duplicate the bug, I used dbus-monitor (--session and --system)
to no real avail. A few errors that I know weren't related, but
nothing of interest. 

I think my initial take on the problem was incorrect, and will report
back after installing today's rawhide. It's probably right that this
version of the bug be closed. 

The closest I've come to finding an actual cause is realizing that
this only happens when another X11 app is running (like firefox), and
is intermittent, but I'm trying to cross-reference pmap -x's of both
and figure out what perhaps changed there. 

Thanks, sorry for the mis-reported bug.

*** This bug has been marked as a duplicate of 135209 ***

rhgb-0.14.1-1 appears to have fixed the problem on my box. 

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.