[ale] Alt+Ctrl+F# blank screens

Michael Trausch mike at trausch.us
Wed Dec 30 17:58:11 EST 2009


On Wed, Dec 30, 2009 at 5:39 PM, Gray Frost <grayf327 at gmail.com> wrote:
> Thanks guys for your responses:
>
> Before we get off track let me recap:  The hardware, all of it,
> monitors, graphics cards, comp have always worked well together and
> using the nvidia drivers that I am using in the same exact setup.  The
> TV was trying to show a VT box because I had swapped the DFP-0 and
> DPF-1 in my many attempts to see different scenarios.  And Yes the is
> was attempting to display something but couldn't.  That was an easy
> fix but it does show that something is trying to work. I destroyed
> that xorg.conf because I had tried so many things and rebuilt a new
> clean one.
>
> Using singe monitor mode provides the VT sessions just fine and also
> in Twin mode with both monitors.  Its just the independent screens
> that causes the grief.  This is a new issue since I have always
> operated with these two monitors set up as independent screens.  My
> problems started with Karmic.  Ps there are other non related issue
> with Karmic that i am not so happy about.

Ahh.  I stopped using independent screens some time ago due to a bunch
of bit-rot in those code paths that I'm not able nor qualified to
clean up—it seems that is a very rare configuration, rare enough that
many bugs are creeping in the stack in various spots (including most
software that used to deal with it just fine, like GNOME).

> After doing hours and hours of research I am convinced that it is a
> Ubuntu Karmic issue with the new Grub2.  in the old grup you could set
> the vga=XXX for your VT terminals but I have found other posting where
> people can not set their VT terminals as you should be able to with
> setting gfxpayload=true in GRUB_CMDLINE_LINUX but it is not working.

I can say (with a good degree of certainty) that GRUB has nothing to
do with it.  The Linux Kernel itself has dropped support for the vga=
parameter, with the kernel writers instead preferring that if you're
going to setup a framebuffer of some sort that you pass parameters to
the modules (or built-in drivers themselves) directly (either on the
kernel command line for built-ins, or the module command line when
loaded with modprobe or similar).  That is the case on new kernels
regardless of what version of GRUB you're using; remember, GRUB is
just the bootloader.  The kernel is what takes control of the system.

> I think that there are some bugs that still need to be ironed out.  I
> think that with the duel monitors it tries to carry the 1680x1050 (or
> the auto) res to the vt terminals which it can't handle in non
> graphics mode.  It is supposed to default to 600x480 or what ever you
> have in the #GRUB_GFXMODE=1024x768 setting.

If you're not running with a framebuffer, then when you switch back
from the VT that X11 is using to a text-mode VT, your display (or both
of them, depending on how the particular card works) is going to use
720x480 (that is, 80x25) for its display mode.  If you are running
with a framebuffer, then it should be switching back to the console
framebuffer's display mode.  If you're not familiar, X11 uses a VT and
puts it in "graphics mode" before using it, which is some sort of hint
to the system that it should not attempt to draw console messages or
any other text I/O there.

Also keep in mind that the graphics mode that GRUB uses is independent
of that which the Linux kernel uses; if you do not configure the
kernel for a graphics mode, it will not use one.  Just because GRUB 2
is capable of using graphics modes to display the menu and so forth
does not mean that those things get passed to the kernel.  On every
system I'm running that has GRUB 2 installed on, the boot menu is
displayed in a graphics mode, but the kernel boots up in plaintext
mode (save for one system that is a friend of mine's; she has an Intel
graphics chipset that works with the new KMS feature and so the kernel
automatically sets up the framebuffer at boot time and X11 reuses it,
providing a very seamless transfer between the console and X11).

> There are others having VT resolution issues I just haven't found a solution.
>
>  http://ubuntuforums.org/showthread.php?t=1346921

In my experience every time there is a problem switching back to the
VT, it's a problem with the driver and nothing else; after all, in the
architecture of X.org, it is the driver's responsibility to restore
the system to the mode it was in prior to taking over the display,
whether that is upon the exit of the X Window System or just a C-A-F1.
 One system that I know of (though the exact card it has I cannot
recall right now) fails to ever return to the console correctly once
the NVIDIA driver has taken over the display (it did work in 9.04, but
the only time the command line is used on the system is by way of
gnome-terminal or ssh, so it isn't a true problem for that system).

> I am seriously considering going back to 9.04 or any other distro
> until this gets resolved.  It is not a killer but not having the
> ability to pop in and out of other VT sessions is like  well...close
> to running Windows.. Aaaahhhhggg.

For me, I use terminal windows like crazy.  It simply takes too long
to switch from the X11 VT to any other VT and back.  If the graphics
subsystem is hung (often happened with one of my other NVIDIA systems,
where the only solution was to find a way to re-POST the video board,
which meant rebooting) then SSH'ing in is the only way to get things
going anyway; and if the system isn't responding to SSH then the only
other thing is to press the big reset button.  Oh, well.

NVIDIA used to be good about responding to my reports of trouble on
their cards.  However, lately, they have completely ignored every
report I have had.  I fought with one chipset (an onboard of theirs)
for a couple of years, sending in bug reports every time the system
was still functional enough to be able to do so.  Never did I receive
a response from them, and never did the problem get fixed.  I am very
close to saying "screw it" when it comes to NVIDIA—especially given my
recent (relatively) good experiences with ATI.

   --- Mike



More information about the Ale mailing list