waitforX

[hiro]

Refering to the old thread:
http://forum.tinycorelinux.net/index.php?topic=6326.msg44618#msg44618

Xorg segfaults when you switch from the VT to Xorg. No input works. But when I startx over ssh I get a working system again.

When I remove waitforX from my .xsession intel KMS suddenly works flawlessly, changing to vt and back, and even s2ram works perfectly.

This is still a bug report, because something in waitforX seems to be responsible in creating this strange, locked up state.

[curaga]

I doubt it's really the culprit, seeing as it's a very simple app that doesn't even run after X has started. It merely waits until X is fully up and exits, so that the WM and other apps can start.

[hiro]

I thought that too, but still it does make a huge difference. It triggers something that on other distros doesn't happen.

[jur]

I commented waitforX out in .xsession to test this whole issue; I can confirm I could suspend to ram without it, and also that X needs to be restarted to make it work properly.

So I replaced waitforX with a sleep=3; X started OK but again s2ram did not work, same problem as before with waitforX.

If I use sleep=3, and restart X before s2ram, then it resumes OK. This does not work with waitforX.

So I would agree it is not waitforX which is the problem.

[hiro]

Do you use Xorg-7.5, and intel KMS? What chipset?

I use a 945GM.

[jur]

Same 945GM chipset, intel KMS, Xorg-7.5.

[hiro]

Very strange. I'm running a thinkpad x60s. I guess I should create a list of my extensions?

How exactly does it lock down for you? Above I already described the events leading to my segfault. After that I can see the frozen console.

How about switching to a vt and back to Xorg, does that create a freeze, a segfault?

[maro]

Whilst on the subject of "bashing" 'waitforX':

(1) A few weeks ago I also stumbled over the fact that 'waitforX' kills the X server when using the 'virtualbox-ose-additions.tcz' extension (e.g. when running TC as a guest in VBox and trying to use the VBox additions). I have not reported this finding as I wanted to do some more testing around it. There were some other things that did not quite work all right, but I got side-tracked and have yet to pick this up again. THe simplistic work-around is again to replace 'waitforX' in '~/.xsession' with something like 'sleep 2'.

(2) Whilst I agree that 'waitforX' looks really "innocent" and simple one thing I believe that should be changed is the fact that it is hard-coded to use display number ':0'. IMHO it should rather use the value of '$DISPLAY' instead to be able to support a multiple X server scenario.

Maybe the issue which causes (1) is realated to the other reported problems. One advantage of getting to the bottom of (1) might be that it does not require specific hardware to test as it all happens in a VM.

[hiro]

What waitforX does: it opens and closes a single connection to the X display. From the docs this will happen if the last connection is closed:

Code: [Select]

Additional processing occurs when the last connection to the X server closes. An X server goes through a cycle of having no connections and having some connections. When the last connection to the X server closes as a result of a connection closing with the close_mode of DestroyAll, the X server does the following:

It resets its state as if it had just been started. The X server begins by destroying all lingering resources from clients that have terminated in RetainPermanent or RetainTemporary mode.

It deletes all but the predefined atom identifiers.

It deletes all properties on all root windows (see section "Properties and Atoms").

It resets all device maps and attributes (for example, key click, bell volume, and acceleration) as well as the access control list.

It restores the standard root tiles and cursors.

It restores the default font path.

It restores the input focus to state PointerRoot.

However, the X server does not reset if you close a connection with a close-down mode set to RetainPermanent or RetainTemporary.http://tronche.com/gui/x/xlib/display/close-operation.html

For me the state it gets reset to is a bad one.

[Juanito]

..and just to confirm deleting "waitforX" fixes suspend to ram with Xorg-7.5 and an i945 for me too 

[hiro]

Good, it only happens after closing the last Xorg client.

Might be we are triggering this bug:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=d75e8146c414bfd512ba5dbd4a83acb334bbe19b