Please attach Xorg.0.log, dmesg, and intel_gpu_dump, according to http://intellinuxgraphics.org/how_to_report_bug.html

It seems that the issue is somewhere in the scanout configuration as the corruption is not apparent in a saved screenshot. Hopefully I'll be able to find a camera to take a picture of the corruption at some point tonight.

Created attachment 26651 [details]
Side by side diff of registers before (right) and after (left) VT switch

Well, I still haven't found a camera for an image. I have, however, found some time to look at the code. It turns out that the palette is getting mangled during VT switching. After dumping the registers before and after a VT switch, I see differences in the beginning of the DPALETTE_B register. While the differences are always at the beginning of the register, the number of mangled bytes varies from instance to instance. However, writing the good values back to the register (using the utility I just sent to the list) fixes the corruption (until the next VT switch, obviously).

One thing I have not yet mentioned is that VTs are currently broken for me. When I attempt to switch to a virtual terminal (e.g. Ctrl+Alt+F1), the xorg image remains on the screen (how is this implemented? Is the framebuffer supposed to be switched to a new buffer?). I can, however, see that the palette corruption occurs when I switch away from the X server. I can verify this with the following steps

0) Sitting in distortion-free X server (VT7)
1) Switch to VT1 (Ctrl+Alt+F1)
2) X server image distorts shortly after, X server is inactive so mouse, etc. is unresponsive
3) Run script to restore palette
4) Distortion disappears
5) Switch back to VT7
6) X server is free of distortion

If I omit step #3 the image will be distorted when I switch back to the X server.

Created attachment 26653 [details]
Script to restore palette

Not sure if this is helpful to anyone but me but here is the script I use to restore the palette (although I only restore the first 120 or so bytes)

It took faaarrrr too long but after all of that I realized that the problem was framebuffer console support (fbcon) not being loaded (DOH! Usually I have it compiled into the kernel; I should make a note of these things). So that problem has been solved.

That being said, it doesn't seem like something like not having fbcon support should result in palette corruption: it shouldn't be necessary to have fbcon to have a distortion-free desktop (correct me if I'm wrong). My guess is that some subsystem is failing to properly keep track of its palette and fbcon just works around this, although that's just my uninformed guess.

Well, the problem is when we switch away with no fbcon loaded, we're switching to nothing.  So the behavior is undefined.  I guess it would be a bit nicer to blank the screen rather than leaving a possibly corrupted image on the screen, but it's really a config issue I think.

(In reply to comment #7)
> Well, the problem is when we switch away with no fbcon loaded, we're switching
> to nothing.  So the behavior is undefined.  I guess it would be a bit nicer to
> blank the screen rather than leaving a possibly corrupted image on the screen,
> but it's really a config issue I think.
> 

Well, I wouldn't simplify it to merely a config issue. It seems to me that even if you have nothing to switch to, things should be fine when you switch back. Having corruption while switched to "nothing" is fine; having corruption after you've returned to xorg seems bad. Shouldn't xorg or someone restore the palette when returning? 

Ah yeah I was a bit hasty.  Switching back should indeed work...

The thing is, we shouldn't be reading or writing any regs in the KMS case that would either corrupt or restore these regs.  Maybe one of the core server VGA routines is messing with the palette through I/O space?

Created attachment 27486 [details] [review]
turn off outputs at leavevt

This patch works on my GM45 test machine at least...  Can you give it a try?

That patch uncovers a kernel bug: the kernel doesn't properly handle restoring CRTC DPMS state at lastclose time...

Closing per discussion on IRC.  Summary:
  - vgacon is likely clobbering the palette here since fbcon never loaded and took over the console
  - vgacon expects the GPU to be in VGA mode, but when KMS is active VGA is no longer an option
  - kernel config can prevent this altogether, by just making sure fbcon is loaded/builtin

*** Bug 22791 has been marked as a duplicate of this bug. ***

i *like* my vga console, so this is a bit of a non-resolution for me ... :}

- the paradigm that whoever feels responsible for the *entered* vt sets up its video mode certainly makes sense (the patch from comment 10 seems counter-productive in that regard - i see potential for flickering when switching between x servers). to do that portably, vgacon would probably have to do an int10 call in a vm86 kernel thread, invoke svgalib's mode3 command via udev/hal/whatever, or something like that.

- conversely, it is completely beyond me, why entering the x server's vt currently requires a properly set up palette (comment 8)

- why is vgacon no option when kms is active? why can't kms stay out of the way as long as vgacon claims the vt? and couldn't the kms module be able to set up text modes in the ideal case?

(In reply to comment #14)
> i *like* my vga console, so this is a bit of a non-resolution for me ... :}
> 
> - the paradigm that whoever feels responsible for the *entered* vt sets up its
> video mode certainly makes sense (the patch from comment 10 seems
> counter-productive in that regard - i see potential for flickering when
> switching between x servers). to do that portably, vgacon would probably have
> to do an int10 call in a vm86 kernel thread, invoke svgalib's mode3 command via
> udev/hal/whatever, or something like that.
> 
> - conversely, it is completely beyond me, why entering the x server's vt
> currently requires a properly set up palette (comment 8)

I think it's likely that something else is writing into the palette space at that point, like vgacon.  When operating with kernel mode setting, the server doesn't handle that case (it assumes the KMS driver is solely in charge).

> - why is vgacon no option when kms is active? why can't kms stay out of the way
> as long as vgacon claims the vt? and couldn't the kms module be able to set up
> text modes in the ideal case?

That's exactly the model we've moved away from.  Thinking about it another way, you don't have a simple wifi driver and a complex one and have complicated handoff code between them right?  That's how the old gfx architecture worked, and it was very fragile and prevented us from doing several things we wanted like panic, debug, etc.

We probably could add a text mode interface to KMS, but thus far there hasn't been a huge demand.  If it's just that fbcon is too slow for you, there's plenty of room for optimization in the low level driver...

(In reply to comment #15)
> I think it's likely that something else is writing into the palette space at
> that point, like vgacon. 
>
likely.

> When operating with kernel mode setting, the server
> doesn't handle that case (it assumes the KMS driver is solely in charge).
> 
i've see that without kms.

> > and couldn't the kms module be able to set up
> > text modes in the ideal case?
>
> We probably could add a text mode interface to KMS, but thus far there hasn't
> been a huge demand.
>
/me signals huge demand and employs self-cloning to make a point. :-D

> If it's just that fbcon is too slow for you, there's
> plenty of room for optimization in the low level driver...
> 
my personal story of intelfb (since 2003) can be summarized as "epic fail".
i'll give it another shot once kms actually works for me.
still it can never be as fast (*) and memory-efficient as a vga text console.
(*) unless the graphics memory is accessed over an internal ISA bridge :D

(In reply to comment #16)
> > When operating with kernel mode setting, the server
> > doesn't handle that case (it assumes the KMS driver is solely in charge).
> > 
> i've see that without kms.

That would be a real bug then...

> > > and couldn't the kms module be able to set up
> > > text modes in the ideal case?
> >
> > We probably could add a text mode interface to KMS, but thus far there hasn't
> > been a huge demand.
> >
> /me signals huge demand and employs self-cloning to make a point. :-D
> 
> > If it's just that fbcon is too slow for you, there's
> > plenty of room for optimization in the low level driver...
> > 
> my personal story of intelfb (since 2003) can be summarized as "epic fail".
> i'll give it another shot once kms actually works for me.
> still it can never be as fast (*) and memory-efficient as a vga text console.
> (*) unless the graphics memory is accessed over an internal ISA bridge :D

Note that the KMS fb driver and the intelfb driver are two different things.  FB_INTEL is pretty much the epic fail you describe unless you're doing something very specific (think of it as an embedded driver).

For a KMS fbcon all you need is the i915 driver and fbcon (CONFIG_FRAMEBUFFER_CONSOLE) enabled.