GeForce4 440 and Nvidia driver problem

pugsley · 12-02-2006, 06:32 PM

I have just installed a GeForce4 440 Go in a Dell Inspiron 8200 laptop. Running Suse10.1 and card works @1600x1400 OK with default NV driver. When installed Suse10.1 Nvidia drivers via YAST the screen is off set with a vertical band of multicoloured fine lines on the RHS. Installing the latest Nvidia drivers manually resuts in no display at all even though the system runs ok and Xserver can be killed. Adding "UseDisplayDevice" "DFP-0" to xorg.conf results in a display but again with the vertical lines. I tried a custom EDID that I found in another forum and that worked Ok except when programs that run full screen cause a lockup. Have reverted to NV driver - has anyone else experienced this problem have a fix?

farslayer · 12-02-2006, 10:34 PM

I have Debian running on my Inspiron 8100 with Nvidia display and it works without a hitch..
I have sen the lines you mentioned, but I only ran into that when using the nv drivers..
Not sure why you are experiencing troubles.,

Maybe something below will trigger an eureka moment for you....

xorg.conf

Code:

Section "Device"
	Identifier	"Generic Video Card"
	Driver		"nvidia"
EndSection

Section "Monitor"
	Identifier	"Generic Monitor"
	HorizSync	30-75
	VertRefresh	50-85
	Option		"DPMS"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Device		"Generic Video Card"
	Monitor		"Generic Monitor"
	DefaultDepth	24
	SubSection "Display"
		Depth		24
		Modes		"1600x1200" "1280x1024" "1024x768"
	EndSubSection
EndSection

lspci

Code:

01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 Go] (rev b2)

xdpyinfo

Code:

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    70101000
X.Org version: 7.1.1
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x200000d, revert to Parent
number of extensions:    30
    BIG-REQUESTS
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    GLX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    NV-CONTROL
    NV-GLX
    RANDR
    RECORD
    RENDER
    SECURITY
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1600x1200 pixels (406x305 millimeters)
  resolution:    100x100 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0xa2
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    64x64
  current input event mask:    0xfa2033
    KeyPressMask             KeyReleaseMask           EnterWindowMask          
    LeaveWindowMask          ButtonMotionMask         StructureNotifyMask      
    SubstructureNotifyMask   SubstructureRedirectMask FocusChangeMask          
    PropertyChangeMask       ColormapChangeMask

pugsley · 12-08-2006, 11:48 PM

Thanks mate for the reply.

I get basically the same out of xdpyinfo other than the resolution being 126x126dpi. It actually apperars that I have a Samsung display with a dud EDID ROM. Using the customer EDID option gives me the correct display and the latest nvidia driver 1931 has sorted the X crash for full screen apps. Happy now.....unitl the next kernal / driver change is suppose.

Getting 2000 frames per second - acceptable I suppose.

Dave