Bug 68030 - startx from run level 3 fails if a window manager is specified in .Xclients
Summary: startx from run level 3 fails if a window manager is specified in .Xclients
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 67218 79579 CambridgeTarget
TreeView+ depends on / blocked
Reported: 2002-07-05 15:38 UTC by Dave Reed
Modified: 2007-04-18 16:43 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-04-20 03:16:39 UTC

Attachments (Terms of Use)
XF86Config file (3.17 KB, patch)
2002-07-05 19:09 UTC, Dave Reed
no flags Details | Diff
XFree86.0.log file (24.10 KB, patch)
2002-07-05 19:09 UTC, Dave Reed
no flags Details | Diff
startx > /tmp/log 2>&1 (995 bytes, patch)
2002-07-05 19:11 UTC, Dave Reed
no flags Details | Diff

Description Dave Reed 2002-07-05 15:38:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605

Description of problem:
specifying a window manager such as twm, sawfish, etc. in the ~/.Xclients file
brings up either a blank screen or a screen with vertical stripes covering the
entire screen when startx is used from run level 3; same setup works fine from
run level 5
gnome starts up fine from run level 3 with startx if there is no .Xclients file

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. choose run level 3
2. create ~/.Xclients file with "exec windowmanager" for some window manager
3. login and enter startx

Actual Results:  screen fills with vertical strips
Ctrl-Alt-Backspace is the only way (other than reset button) to get
out; no mouse cursor, etc.

Expected Results:  appropriate window manager should start from run level 3
I use run level 3 since I enter my ssh passphrase and use ssh-agent before
starting X so the passphrase doesn't need to be retyped in each terminal window

Additional info:

Riva 128 video card

Comment 1 Owen Taylor 2002-07-05 17:32:23 UTC
Almost certainly an X server bug.

What video card?

Attaching your /etc/X11/XF86Config-4 and the output of startx
(startx > /tmp/log 2>&1) will also probably be helpful.

Comment 2 Dave Reed 2002-07-05 19:07:19 UTC
While I suppose it's possible it's an X server bug, I wonder why the window
managers start fine when it's already at run level 5?

The video card is a Riva 128 - I believe it's an NVidia card prior to the TNT
cards - my brother gave it to me a couple years ago. It did work when Red Hat
7.2 and 7.3 were installed on the machine and it does currently work in run
level 5. This is my "test machine" so it's got some old parts. My "main machine"
has a Radeon 7500, but I'm not ready to try the beta on my "production" machine.

There's only an XF86Config (not a XF86Config-4 file), although rpm -qa|grep
XFree seems to indicate only XFree 4 is installed.

I'm attaching the "XF86Config" file, the "log" file from running the startx
command, and the XFree86.0.log file.

Have any of you tried running startx from run level 3 and specifying a window
manager in your ~/.Xclients file (twm or sawfish produce similar problems)?

Comment 3 Dave Reed 2002-07-05 19:09:05 UTC
Created attachment 63854 [details]
XF86Config file

Comment 4 Dave Reed 2002-07-05 19:09:56 UTC
Created attachment 63855 [details]
XFree86.0.log file

Comment 5 Dave Reed 2002-07-05 19:11:45 UTC
Created attachment 63856 [details]
startx > /tmp/log 2>&1

Comment 6 Dave Reed 2002-07-06 01:59:29 UTC
I think fvwm2 may actually be running even though there are just stripes. If I
press the keyboard accelerators to change workspaces, the stripes do change colors
so maybe it is running and different workspaces have different stripes.

And sometimes I see the inital cross-hatch (that IIRC X starts with) for a few
seconds before the stripes. I've got the line: xsetroot -solid "#000000"
in my .Xclients so each workspace should be all black.

Comment 7 Mike A. Harris 2002-07-10 05:06:25 UTC
Use ~/.xinitrc instead.

Comment 8 Dave Reed 2002-07-10 12:02:56 UTC
~/.xinitrc is a symlink to ~/.Xclients

I did: rm .xinitrc; mv .Xclients .xinitrc
but that didn't change anything.

Comment 9 Mike A. Harris 2002-07-30 00:02:10 UTC
The log file attached is that of a working session.  I need the log file
from a session which does not work.

Comment 10 Mike A. Harris 2002-07-30 00:03:59 UTC
The second log file seems to show that your .xinitrc might be misconfigured.

Comment 11 Dave Reed 2002-07-30 12:03:33 UTC
I'm beginning to think Owen is correct - it must be a video driver issue.
My .xinitrc is very plain. I've even tried it with just:

exec twm

and it still doesn't work.

Comment 12 Mike A. Harris 2002-08-06 08:48:17 UTC
This whole bug report doesn't make a lot of sense to me.

Either the video driver works or doesn't work.  The window manager
doesn't enter into it.  I've no idea what could be causing the problem
you're seeing, but it doesn't occur with any cards I try locally.

I do not have Nvidia hardware supported by the "nv" driver.  Someone
who has this hardware will need to debug the issue to see what is
happening that is causing this problem.

Comment 13 Dave Reed 2002-08-06 14:04:36 UTC
It's really not a big deal to me since this is my "test" machine; my main machine
has a Radeon 7500 which the next official release will be installed on. If there's
anything I can do that's not too much work, I'm willing to try but I don't want
to spend a lot of time on it since this is old hardware that very few people
will have.

Comment 14 Karsten Hopp 2002-08-20 12:32:14 UTC
I've seen this several times with my Geforce2 card. It seems that the card isn't
initialized properly. A workaround for me was to switch to a different
resolution witch Ctr-Alt-<keypad +> and back to the original resolution.
Does this work for you ? (You need to have at least 2 different modes configured
fox X)

Comment 15 Dave Reed 2002-08-21 20:48:25 UTC
I installed the new beta (null) and when I first typed startx, I just got a blank
screen with the x cross-hair cursor. I then hit ctrl-alt-<keypad +> and then the
windowm manager took over and worked.


Thanks for the workaround.

Comment 16 Mike A. Harris 2002-11-07 11:58:41 UTC
Please try the latest developmental XFree86 CVS packages from:


Do the new XFree86 packages solve this problem for you?

Comment 17 Dave Reed 2002-11-08 01:21:11 UTC
The new packages don't help. I still need to cycle through the sizes using 
ctrl-alt-<keypad +> before it looks ok. It's definitely something with the
nv driver. I finally got around to installing 8.0 on my laptop and everything
is fine there with the same setup (except it has an ATI video chipset).

Comment 18 Mike A. Harris 2004-04-20 03:16:39 UTC
This definitely seems to be an 'nv' driver bug.  If the problem still
exists in current generation Fedora Core 2 test2 or later with
X.org X11, please report the issue upstream via:

http://bugs.freedesktop.org against the 'xorg' component, and
paste the upstream bug URL here for us to track the upstream
driver maintainer's resolution.  There's not really a lot we can
do for 'nv' driver related bugs other than get the reporter to
test if disabling acceleration solves the issue and then hard
code in the driver to disable acceleration, or to do finer
grain testing with XaaNo options (as per XF86Config manpage) and
disable just the flawed primative.

In this case however, it seems that the EnterVT/LeaveVT code is
probably not setting up the card or restoring it properly, and
doing a VTswitch flips something in to place.  Someone with
physical access to this hardware, and the databooks would need
to investigate it to fix, which is probably only possible via

Closing as WONTFIX.

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