Working: Toshiba Sat Pro 6100 and NVIDIA legacy driver at 1600x1200

[Dr. Gary E. RAFE]

The following is for the archives,
in case someone might find this information useful.

I had some free time between projects this weekend,
so returned to the problem of getting the NVIDIA-supplied
native X11 OpenGL driver to work on my (old) Toshiba Satellite Pro 6100.
This notebook uses the NVIDIA GeForce4 420 Go [NV17M]
graphics chipset with 16MB of video RAM and a 1600x1200 resolution
flat panel display.

Years ago (running 4.x-R and earlier 5.x-R), the native NVIDIA
drivers "just worked" on this notebook.
Then, about 5.3-R or 5.4-R, the available driver at the time stopped
recognizing the full resolution of the internal flat panel display,
interpreting the EDID resolution as 1588x1200, rather than the actual
1600x1200.

My investigations started with the current "legacy" version of the
native driver, NVIDIA-FreeBSD-x86-96.43.01.
With the source patches from the Ports collection,
this compiled and installed without complaint.
Starting X (XFree86-4.7.0 compiled from source), however,
resulted in an all-too-familiar washed-out, corrupted graphics display.
The X server did start, however, and the system was still usable.
Killing the X server remotely returned the previous VT console,
so the situation did not seem terminal.

I next took a look at the older "legacy" release,
NVIDIA-FreeBSD-x86-71.86.01.
Again, this compiled and installed without complaint,
and started up the very first time.
Unfortunately, the display was missing a 12 pixel-wide band
along the right edge, as it had in my last encounter with the
native driver.

New research suggested that the EDID returned from the chipset/display
was the culprit here.
Using the native-driven X server, "XFree86 -logverbose 10 -probeonly"
returned the 128-byte EDID structure, with the offending byte exactly
where it was supposed to be (byte 0x38).
Using bvi(1), I reconstructed a new, custom EDID binary file with the
correct data in byte 0x38 (here, 0x40 to indicate 1600 pixels wide).

Since the older legacy drive does not support custom-EDIDs,
I reinstalled NVIDIA-FreeBSD-x86-96.43.01,
configured it to use the new, custom 128-byte EDID,
and it worked properly the very the first time.

Performance with this legacy driver seems reasonable,
as reported by glxgears(1): approx 1160 FPS, compared to 350 FPS
with the (unaccelerated) XFree86 "nv" driver, but, alas,
not as good the older legacy driver (1825 FPS).

Some additional configuration issues:

The EDID-supplied display size values are close, but not very accurate.
This is fixed by *not* using the EDID-calculated DPI information.

ACPI suspend/resume works, albeit, not as expected.
My suspend script switches the VT to ttyv0 prior to suspend,
and have /etc/rc.resume switch back to the approriate VT
if X is running.
Upon ACPI resume, the text console is *not* visible.
The automatic VT switch in /etc/rc.resume, however,
brings the display back correctly, so this is a minor issue.
I did build an nvidia.ko kernal module with ACPI enabled
to see if this might have an affect on the resume behavior.
Using this kernel module, however, caused the ACPI suspend to fail (!).
So, I can live with a working, albeit, unexpected, suspend/resume.

Kernel module settings for this configuration:
  hw.nvidia.registry.NvAGP=1
  hw.nvidia.registry.SoftEDIDs=0
  hw.nvidia.registry.Mobile=2

Relevant XF86Config entries:
Section "Monitor"
   Identifier  "Monitor:builtin"
   VendorName  "Toshiba"
   ModelName   "Satellite Pro 6100 1600x1200 Flat Panel Display"
   DisplaySize 305 229
   HorizSync   29.0 - 76.0
   VertRefresh 40.0 - 60.0
EndSection #Monitor

Section "Device"
   Identifier "Device:nvidia"
   Driver     "nvidia"
   VendorName "NVIDIA Corporation"
   BoardName  "NV17M [GeForce4 420 Go]"
   VideoRam   16384
   BusID      "PCI:1:0:0"
   Option     "UseDisplayDevice" "DFP-0"
   Option     "CustomEDID" "DFP-0:/etc/X11/edid-nvidia16m.bin"
   Option     "UseEdidDpi" "False"
   Option     "RenderAccel" "True"
   Option     "DamageEvents" "True"
   Option     "BackingStore" "True"
EndSection #Device
--
Dr Gary E RAFE: drgerlists at gmail dot com