VC garbled after starting X

robot5x · 2005-08-26 10:25:14

Hi all -
I've mucked about with my xorg.conf quite a bit to get tvout working with my nvidia card. Problem is that whenever I start x and then exit back to the console all I can see is big flashing green blobs which makes doing anything kind of difficult. Must be something wrong with my xorg.conf since this happens with flux, wmi e17 and others. In case its relevant I changed my cpu and mainboard a few weeks ago and noticed quite a hit in frames on glxgears.... anyway my xorg.conf is below in case anyone can point out something I'm missing.
System specs are athlon64 3000 on a DFI lanparty ut nf3 ultra, nvidia ti4400 using latest driver 7676 (not arch package).

Section "Module"
# This loads the DBE extension module.

    Load        "dbe"   # Double buffer extension

# This loads the miscellaneous extensions module, and disables
# initialisation of the XFree86-DGA extension within that module.
    SubSection  "extmod"
      Option    "omit xfree86-dga"   # don't initialise the DGA extension
    EndSubSection

# This loads the font modules
    Load        "type1"
#    Load        "speedo"
    Load        "freetype"
#    Load        "xtt"

# This loads the GLX module
    Load       "glx"
# This loads the DRI module
#    Load       "dri"
EndSection

Section "Files"
    RgbPath     "/usr/X11R6/lib/X11/rgb"

    FontPath   "/usr/X11R6/lib/X11/fonts/terminus/"
    FontPath   "/usr/X11R6/lib/X11/fonts/misc/"
    FontPath   "/usr/X11R6/lib/X11/fonts/TTF/"
    FontPath   "/usr/X11R6/lib/X11/fonts/Type1/"
    FontPath   "/usr/X11R6/lib/X11/fonts/CID/"
    FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/"
    FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/"
    FontPath   "/usr/X11R6/lib/X11/fonts/local/"
#    FontPath   "/usr/X11R6/lib/X11/fonts/Speedo/"
#    FontPath   "/usr/X11R6/lib/X11/fonts/TrueType/"
#    FontPath   "/usr/X11R6/lib/X11/fonts/freefont/"
EndSection

Section "ServerFlags"
EndSection

Section "InputDevice"
    Identifier  "Keyboard1"
    Driver      "kbd"
    Option "AutoRepeat" "500 30"
    Option "XkbRules"   "xorg"
    Option "XkbModel"   "pc104"
    Option "XkbLayout"  "gb"
EndSection

Section "InputDevice"
    Identifier  "Mouse1"
    Driver      "mouse"
    Option "Protocol"    "IMPS/2"
    Option "ZAxisMapping""4 5"
    Option "Device"      "/dev/misc/psaux"
EndSection

Section "Monitor"
    Identifier  "Liteon"
    HorizSync   31.5 - 57.0
    VertRefresh 50-100
    # HorizSync   31-60
    # VertRefresh 55-75
EndSection

Section "Monitor"
    Identifier  "TV"
    HorizSync   30-50
    VertRefresh 60
EndSection

Section "Device"
    Identifier  "Standard VGA"
    VendorName  "Unknown"
    BoardName   "Unknown"
    Driver     "vga"
EndSection

Section "Device"
    Identifier  "nvidia4400"
    Driver      "nvidia"
    Option      "NoLogo"        "true"
    Option      "CursorShadow"  "true"
    Screen      0
    # BusID     "PCI:02:00:0"
    # VideoRam    131072
EndSection

Section "Device"
    Identifier  "nvidia4400tvout"
    Driver      "nvidia"
    Option      "noLogo"        "true"
    Option      "TVStandard"    "PAL-I"
    Option      "TVOutFormat"   "SVIDEO"
    Screen      1
    # BusID     "PCI:02:00:0"
    # VideoRam  131072
EndSection

Section "Screen"
    Identifier  "MonitorLiteon"
    Device      "nvidia4400"
    Monitor     "Liteon"
    DefaultDepth 24
    Subsection "Display"
        Depth       8
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    # BusID     "PCI:02:00:0"
    # VideoRam    131072
EndSection

Section "Device"
    Identifier  "nvidia4400tvout"
    Driver      "nvidia"
    Option      "noLogo"        "true"
    Option      "TVStandard"    "PAL-I"
    Option      "TVOutFormat"   "SVIDEO"
    Screen      1
    # BusID     "PCI:02:00:0"
    # VideoRam  131072
EndSection

Section "Screen"
    Identifier  "MonitorLiteon"
    Device      "nvidia4400"
    Monitor     "Liteon"
    DefaultDepth 24
    Subsection "Display"
        Depth       8
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       16
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       24
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
EndSection

Section "Screen"
    Identifier  "Tvout"
    Device      "nvidia4400tvout"
    Monitor     "TV"
    DefaultDepth 24
    Subsection "Display"
        Depth   24
        Modes   "1280x1024" "1152x864" "1024x768" "800x600"
    EndSubsection
EndSection

Section "ServerLayout"
    Identifier  "MonitorTV"
    Screen      0 "MonitorLiteon"
    Screen      1 "TVout" RightOf "MonitorLiteon"
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"
EndSection

Thanks!

Mr Green · 2005-08-26 10:41:22

Do your Xorg logs tell you anything ?

phrakture · 2005-08-26 15:15:33

Are you using a framebuffer... try setting it to vesafb (video=vesafb) - sometimes the nvidia driver screws things up when it's loaded "on top of" a framebuffer

nightfrost · 2005-08-28 10:02:33

I have the exact same symptoms whenever I resume from a suspend (in either X or console, doesn't matter) IF I'm using framebuffer (any driver). I have an intel 855GM. I was thinking perhaps there's some sort of utility which can restore the console after it's garbled. Does anyone know if there's such a thing? Cause if there is, it would solve both of our problems

robot5x · 2005-08-28 10:09:31

yeh - thanks phrakture, it was indeed a framebuffer issue as nightfrost says too. at the moment I've got rid of the framebuffer since its more important to me to be able to use the console after a suspend - but would be nice to find a fix for this.

Machiavelli · 2005-08-30 19:38:25

I was recently up to my ass in this. What you're aiming for is a kernel with support for vesafb-tng. However, there are some traps:

First off, I used the archck PKGBUILD from the AUR. This also includes drivers for the shfs filesystem, and that doesn't originally go so well with gcc 4. I disabled the shfs in the config (unset CONFIG_SH_FS), but appearently there's some sort of patch for this too. Whatever floats your boat.

With vesafb-tng installed, your console won't be garbled, but rather, you will simply face a black screen and a hangup when trying to switch back to vc. At least if you, like I, had SMP support in your kernel. On the vesafb-tng webpage I found information regarding this oddity, and recompiled without support for SMP.

Now everything works great.

nightfrost · 2005-08-30 19:54:22

It must feel great to have that solved. I have tried tng though, and I still have the same garbled screen. I've been trying to get intelfb working hoping that it will be my saviour, but that just doesn't work either...

Machiavelli · 2005-08-30 21:09:41

nightfrost wrote:

It must feel great to have that solved. I have tried tng though, and I still have the same garbled screen. I've been trying to get intelfb working hoping that it will be my saviour, but that just doesn't work either...

That is strange... on the project page, in the functions list, it clearly states:

use the console with vesafb and have X running with nVidia binary drivers.

I also read somewhere that the screen refresh rate you are running vesafb with must be in the range of the X refresh rate, but for me this worked anyhow.

Anyway... here are my relevant configurations, maybe this will help:

[root@gatubarn boot]# cat kconfig26archck | grep FB_VESA
CONFIG_FB_VESA=y
# CONFIG_FB_VESA_STD is not set
CONFIG_FB_VESA_TNG=y
CONFIG_FB_VESA_DEFAULT_MODE="640x480@60"
[root@gatubarn boot]# cat kconfig26archck | grep CONFIG_SMP
# CONFIG_SMP is not set
[root@gatubarn boot]# cat grub/menu.lst
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,1)
#          kernel /vmlinuz-version ro root=/dev/hda4
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10
splashimage=(hd0,1)/grub/splash.xpm.gz
title Arch Linux 2.6.12 ARCHCK
        root (hd0,1)
        kernel /vmlinuz26archck root=/dev/hda4 video=vesafb:1024x768-32@57 splash=verbose,theme:darch quiet console=tty1
        initrd /fbsplash-darch-1024x768

(...)

Good luck.

keevn7 · 2005-08-30 21:19:55

Another warning about vesa-tng is that it lagged my 3D Acceleration. It dropped the FPS by about 500 in glxgears, and caused random hiccups. I restarted X then the system, in case that somehow worked, with no avail. Then I took vesa-tng out of the kernel and it stopped, so if you play 3D games, do 3D rendering or whatever else then I would keep away from vesa-tng.

nightfrost · 2005-08-30 21:21:19

Thanks for the info. I'll be playing around a bit more, but I'm not having high hopes. I'll post back here if anything new comes up.

The most annoying thing with the trouble shooting is the constant need for reboots, so I'm not gonna try more tonight

nightfrost · 2005-08-30 21:26:15

just out of curiousity though; would it be (even theoretically) possible to use whatever code initializes the framebuffer when one boots the computer, and have it run after a resume to "re-initialize" the screen. That is, would it be possible to "reboot" the screen?

Machiavelli · 2005-08-30 22:17:19

keevn7 wrote:

Another warning about vesa-tng is that it lagged my 3D Acceleration. It dropped the FPS by about 500 in glxgears, and caused random hiccups. I restarted X then the system, in case that somehow worked, with no avail. Then I took vesa-tng out of the kernel and it stopped, so if you play 3D games, do 3D rendering or whatever else then I would keep away from vesa-tng.

Is that so? I notice no real difference in neither glxgears nor Soldier of Fortune 2. :?

Still, in retrospect I can't even remember why I wanted fbsplash to begin with (I sorta miss my old boot). And if there's a reason to avoid it, I guess I should be a little careful recommending vesafb-tng to anyone who wants a nice bootsplash.

nightfrost · 2005-08-30 22:29:00

Actually, what you say is really worth thinking about. There is something about that bootsplash eyecandy that makes people want it badly (me included at times), but - and this is especially true with Arch - it's only a few seconds worth of enjoyment before X kicks in. There's a really uneven balance between the amount of time one gets to enjoy the eyecandy and the amount of time one puts down in order to get it all working

Arch Linux

#1 2005-08-26 10:25:14

VC garbled after starting X

#2 2005-08-26 10:41:22

Re: VC garbled after starting X

#3 2005-08-26 15:15:33

Re: VC garbled after starting X

#4 2005-08-28 10:02:33

Re: VC garbled after starting X

#5 2005-08-28 10:09:31

Re: VC garbled after starting X

#6 2005-08-30 19:38:25

Re: VC garbled after starting X

#7 2005-08-30 19:54:22

Re: VC garbled after starting X

#8 2005-08-30 21:09:41

Re: VC garbled after starting X

#9 2005-08-30 21:19:55

Re: VC garbled after starting X

#10 2005-08-30 21:21:19

Re: VC garbled after starting X

#11 2005-08-30 21:26:15

Re: VC garbled after starting X

#12 2005-08-30 22:17:19

Re: VC garbled after starting X

#13 2005-08-30 22:29:00

Re: VC garbled after starting X

Board footer