Are you sure that the display is actually compressed into the top few scanlines? e.g. do you see the mouse cursor in there when you move it around? Does it show your normal background? Or is it just garbage that happens to not have 0's for the top few scanlines' worth of data?

I've never used PreferredMode before. If you remove it, I assume everything works fine? What happens if you run something like

xrandr --output DVI-I-1 --mode 1920x1440

does that fix things for you? Can you supply the output of

xrandr --verbose

after X has started? (You can e.g. ssh in and run DISPLAY=:0 xrandr --verbose)

Created attachment 85420 [details]
verbose xrandr output per comment infra

(In reply to comment #1)
> Are you sure that the display is actually compressed into the top few
> scanlines? e.g. do you see the mouse cursor in there when you move it
> around?

I started working out this problem 3 months ago. I spent mucho hours trying to separate it from other bugs at the time. It took me more than two days. A small sample of the 93 saved logs from that time:
http://fm.no-ip.com/Tmp/Linux/Xorg/PrefMode/

As the session begins to open I see the wallpaper colors, which later change as Konsole and the panel should be painted. But, I can see the tip of the mouse pointer in it at times.

> Does it show your normal background?

Can't really tell. My *normal* background is usually hidden under a pile of windows.

> Or is it just garbage that
> happens to not have 0's for the top few scanlines' worth of data?

It's clearly a color pattern based upon the wallpaper and the panel and Konsole.
 
> I've never used PreferredMode before. If you remove it, I assume everything
> works fine?

Yup. Without it happily uses the EDID preference instead of mine.

> What happens if you run something like

> xrandr --output DVI-I-1 --mode 1920x1440
 
> does that fix things for you? Can you supply the output of
 
> xrandr --verbose
 
> after X has started? (You can e.g. ssh in and run DISPLAY=:0 xrandr
> --verbose)

Instead of trying to figure out ssh, I made this script:

xrandr --verbose  > xrandrout.txt
echo mark >> xrandrout.txt
xrandr --output DVI-I-1 --mode 1920x1440
echo mark >> xrandrout.txt
xrandr --verbose  >> xrandrout.txt

I closed a working prior session with Konsole open, added back to configfile the non-working PreferredMode, started new session, and after a short wait for Konsole to get open I ran the script.

It changed nothing WRT to the bug, display still mostly just black. Good thing Ctrl-Alt-BS works.

What if you run

xrandr -s 1920x1440 -r 60

I wonder if something's breaking down at the 75Hz refresh rate it ends up picking. (You can do this from a "working" session, it should just switch resolutions... you can also be careful about it and do like xrandr -s 1920x1440 -r 60 && sleep 10 && xrandr -s 1600x1200 to make sure that you get back to a working state.)

'xrandr -s 1920x1440 -r 60 && sleep 10 && xrandr -s 1600x1200' scrunched everything into the top 1/8" of the display and after a brief sleep restored the working EDID preferred 1600x1200 state.

OK, so this has nothing to do with setting the PreferredMode. Good, that would have been weird. Something's not being computed correctly. I wouldn't be surprised if the mode data in the EDID were somehow wrong for those modes, and other drivers are just better at dealing with the incorrectness. Or perhaps we're setting some clock incorrectly.

1920x1440 was an example of a broken mode >EDID preferred. The broader description is xorg.conf* PreferredMode is broken WRT all traditional 4:3 modes higher than the EDID preferred mode, same as those modes set via xrandr -s. Other broken modes on this FE2111SB/G84 combination include 1792x1344 and 1856x1392, proven using comment 4 method. Interestingly, this CRT has previously proven to have no objection to non-4:3 modes, and 'xrandr -s 1920x1200 -r 60 && sleep 10 && xrandr -s 1600x1200' does not produce this bug, just a normal 1920x1200 squeezed into a 4:3 space for the sleep duration. 1920x1080, 1440x900 and 1680x1050 also work in same manner. Both 1920x1200 and 1920x1080 (and presumably 1440x900 and 1680x1050) work via PreferredMode as well.

Considering the dozens of gfxchips using non-nouveau drivers I've connected via VGA outputs to this CRT exhibiting no such trouble, I doubt EDID is the root. Using this very same G84 and DVI to VGA adapter with nv driver and disabled KMS this CRT works as well as Intel and Radeon and even does 2048x1536@60.

Up until recently, we defaulted to forcing panel scaling by default (except for VGA). Perhaps we were misdetecting something wrt auto-enabling it (normally disabled for VGA). Does this still happen with recent kernels? Or with the randr property 'scaling mode' set to 'None'?

The NEC FE2111SB of comment 0 is no longer available. With a Sony Trinitron G520 this is not reproducible with any kernel/server/nouveau combination tried, including k3.7.10/s1.13.2/n1.0.6, k3.11.10/s1.14.3/n1.0.9, k3.16.7/s1.16.1/n1.0.11 and k4.2.3/s1.17.2/n1.0.11 among others, all using the same G84 and 32 bit Prescott host. So I'm of the opinion this was more likely a CRT quirk than a nouveau bug.