Bug 68030
Summary: | startx from run level 3 fails if a window manager is specified in .Xclients | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Dave Reed <dreed> | ||||||||
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> | ||||||||
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 8.0 | ||||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i386 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2004-04-20 03:16:39 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 67218, 79579, 100644 | ||||||||||
Attachments: |
|
Description
Dave Reed
2002-07-05 15:38:53 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. 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)? Created attachment 63854 [details]
XF86Config file
Created attachment 63855 [details]
XFree86.0.log file
Created attachment 63856 [details]
startx > /tmp/log 2>&1
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. Use ~/.xinitrc instead. ~/.xinitrc is a symlink to ~/.Xclients I did: rm .xinitrc; mv .Xclients .xinitrc but that didn't change anything. The log file attached is that of a working session. I need the log file from a session which does not work. The second log file seems to show that your .xinitrc might be misconfigured. 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. 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. 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. 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) 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. Bizzare. Thanks for the workaround. Please try the latest developmental XFree86 CVS packages from: ftp://people.redhat.com/mharris/testing/live-grenades/XFree86 Do the new XFree86 packages solve this problem for you? 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). 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 upstream. Closing as WONTFIX. |