X works wonderfully for me until I switch to another virtual terminal (by pressing ctrl-alt-f1, for example). If I try to go back to X (with alt-f7), all I see is a blank screen. From this point, the only way for me to start use x correctly is by rebooting the computer.

It appears that my keystrokes are still interpreted as if I could see what was on the screen, but everything is black.

ctrl-alt-+ or ctrl-alt-- cause the black screen to go off (a much darker black) for a short time (like when the display works), but then that blank black screen returns.

From the virtual terminal, if I try to do stuff on the blank display, I get something like this:

xsetroot -solid blue -display localhost:0
xsetroot: unable to open display 'localhost:0'

Trying localhost:0.0, or localhost:1.0 makes no difference.

Any ideas?

I'm running debian (etch beta 3) with fvwm (though I'm sure the window manager isn't part of the problem), on my dell dimension 2400.

Instead of alt-F7, as root do "/etc/init.d/gdm start" (without the quotes). If you are not using gdm as your display manager, replace gdm with kdm or xdm respectively in the above command.

"Starting X display manager: xdm already running."

So I killed the xdm that was running (kill 3069), and tried /etc/init.d/xdm start again. It brought me to that blank black screen again.

Just after I had killed the old xdm and before starting the new one, when I did alt-F7, I saw a black screen (not the blank black one, just the black one) with a small white cursor blinking in the upper left hand corner.

you don't say what kind of video hardware/drivers you use...

I have previously had problems with older(than the latest 8776) versions of Nvidia's binary modules and switching from X to a VT and back. It was similar except my display would not be blank, it was like corrupted ncurses or something, in various colours. it only did this for me when I was using a vesa framebuffer console, using standard low-res vga it doesn't do this. Could very well be something else though, but if you're using nvidia you should try a standard VGA console and see if it still happpens.

I don't think I'm using nvidia. How do I figure that out?

I have an Intel 845G chipset (and Graphics Controller?)

What does it mean to try a standard VGA console? How can I do that?

$lspci | grep VGA

should list whatever graphics controller(s) you are using. I'm pretty confident the problem I had was with Nvidia's official driver, so if you don't use it then I doubt my problem was the same as yours, and probably my solution won't make a difference.

usually in your bootloader's config file there is an entry like vga=790 (or similar) that defines a higher resolution VESA framebuffer console. For GRUB, IIRC, this entry is on the kernel invocation line for a given menu selection in menu.lst. Simply removing the vga=xxx option does the trick for me(getting the VT switch glitches to not happen). In LiLo, there is a single vga=xxx line for the whole config, vga = normal is what I used to avoid the glitch I mentioned on my slackware install.

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

I played a little with the vga= in menu.lst for grub, but it didn't change anything.

I am getting this error message in /var/log/Xorg.0.log:
(EE) AIGLX: Screen 0 is not DRI capable

Is that a problem?

I tried out a knoppix live cd, and switching between virtual terminals and X worked fine. If I do dmesg | grep drm on the knoppix, I get stuff back, but I don't on the debian. Could that be a problem?

It works!

I ran dpkg-reconfigure -phigh xserver-xorg, and when it asked for the driver, I said i810 rather than vesa.

Now I can go back and forth to and from X and Virtual Terminals at will.

And as a bonus, the problems I was having with scrolling on firefox have gone away.

1 members found this post helpful.

glad to hear you got it sorted. sorry I could not offer more assistance when you needed it.