Description of problem: Using virtual terminals causes X windows to be unsusable.
Version-Release number of selected component (if applicable):
00:02.0 VGA compatible controller: Intel Corporation 82G965 Integrated Graphics
Controller (rev 02)
Start a virtual terminal. [Allow GDM to localhost]
Steps to Reproduce:
1. X :1 -query localhost
2. Switch back to first terminal [ctrl-Alt-F7]
White screen. Switching back to F8 gets a solid blue screen.
Usuable virtual consoles
Have read and understood release note about greyscale rendering. Have not edited
fonts. [Release note -
Logging in remotely to a Gnome desktop via gdm may cause several display issues.
The login screen may hang, displaying an unusable empty screen.
To prevent this from occurring, do not change the default font rendering setting
of grayscale. If the default font rendering setting has been edited and you
encounter this problem, run the following command:
gconftool-2 --direct --config-source=$(gconftool-2 --get-default-source) --set
/desktop/gnome/font_rendering/antialiasing --type string grayscale
xorg-x11 is not correct component for RHEL5.
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 190261 [details]
[mgt@dwarfstar ~]$ uname -a
Linux dwarfstar.stellarcore.net 2.6.18-8.1.8.el5xen #1 SMP Tue Jul 10 07:06:45
EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 190271 [details]
Xorg.0.log during test with no xorfg.conf file
Created attachment 190281 [details]
Xorg.1.log from test with no xorg.conf on virtual terminal
I have submitted the attachments as requested and conducted the test of Xorg
with no xorg.conf file in place. The issue is still there although in this case
it took 3 terminal changes to cause the bug. I booted into init 5 and logged in.
I then changed to text terminal ala Crtl-Alt-F1 and started another session with
the command X :1 -query localhost. Once another graphics terminal started up I
logged into that as well. Then with a Ctrl-ALT-F7 and changed to the original
window movede around, CTRL-Alt-F8 to return to new terminal everything was fine.
Then I went to CTRL-ALT-F1 and when I returned to CTRL-ALT-F7 the ternminal
I was doing so further fiddling with my xorg.conf and can confirm that the issue
seems to be in the i810 driver. When I switch to vesa the issue goes away.
Some more comments.
I updated the motherboard BIOS [and therefor the video BIOS] was at the lastest
greatest rev. [1707 in this case]. No effect.
I grabbed the i810 package from the Fedora 7 tree [
xorg-x11-drv-i810-2.0.0-4.fc7.src.rpm ] and with minimal hacking I was able to
build and install that. No effect the problem still exists.
Two years have passed now. Is this problem still present? Thanks.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.
Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.
Closing as INSUFFICIENT_DATA.
I honestly have no idea if this is still the case. It was 2 years before this was even commented on so I guess I was out in the wilderness alone with this problem. I ended up having to use Xnest for my needs and eventually changed desktops [Mac Mini OSX]. I think I provided sufficient information with the original bug report that the Intel chipset had issues with the released X server driver and testing it was pretty straight forward. Hopefully it was fixed in later releases.