Sounds like yet another tiling bug - with a twist that the kernel/userspace view of tiling is consistent, i.e. the readback is correct. The only other place that springs to mind for a potential cause of tiling corruption on the display is incorrect settings applied to the pipe.

Till, can you upload the output of xrandr so that we can see the size of the pixmaps involved and intel_reg_dump so that we can see what settings we've applied to the display?

Jesse, "in-memory fine, on-screen corrupted, ergo display regs are wrong" does that sound plausible or can you think of another cause for this bug?

Hi Chris,

thanks for looking into this.
I just upgraded to latest libdrm and ddx.

Created attachment 36211 [details]
xrandr output

Created attachment 36212 [details]
intel_reg_dump (screen orientation set to normal)

Created attachment 36213 [details]
intel_reg_dump (screen orientation set to left) *corrupted display output*

For testing purpose I changed connection from DVI1 to VGA1,
but then I could not use '--orientation left/normal' at all.

While this might be a different bug, this is the xrandr output:

>xrandr --orientation {left,normal}
X  Error  of  failed request:  BadValue (integer parameter out of
range for operation)
  Major opcode of failed request:  149 (RANDR)
  Minor opcode of failed request:  2 (RRSetScreenConfig)
  Value in failed request:  0x0
  Serial number of failed request:  14
  Current serial number in output stream:  14

First of(In reply to comment #6)
> For testing purpose I changed connection from DVI1 to VGA1,
> but then I could not use '--orientation left/normal' at all.
> 
> While this might be a different bug, this is the xrandr output:
> 
> >xrandr --orientation {left,normal}
> X  Error  of  failed request:  BadValue (integer parameter out of
> range for operation)
>   Major opcode of failed request:  149 (RANDR)
>   Minor opcode of failed request:  2 (RRSetScreenConfig)
>   Value in failed request:  0x0
>   Serial number of failed request:  14
>   Current serial number in output stream:  14

Seems like the xrandr error above is not reproducible straight forward and only happens when I change randr settings a few times. As if there where some remnants that cause you trouble eventually even in a previously well-known working configuration. But that is surely another thing...

Back to the corruption issue:
I only tested this with the native panel resolution of 1680x1050.
It's a DELL 2090WE, btw.

Checking all available modes for VGA1 and DVI1 I found out that all modes work fine apart from 1680x1050 and 800x600. This seems to be independent from connector type. I first thought it could be due to the aspect ratio but since 800x600 also causes trouble this seems unlikely to me.

Allow me a side question:
Why is it that the modes listed in xrandr are not listed in a descending way?
Is this a driver thing or given by the EDID?
So all auto configuration give me 1280x1024 resolution to start with, which is not the most sensible thing to do, imho.

Till, hmm I don't think it's actually a simple tiling mode mismatch any more. Can you upload a screenshot?

The oddity I found in the registers exists for both...

working config:
            DSPACNTR: 0xd8000400 (enabled, pipe A)
          DSPASTRIDE: 0x00001c00 (7168 bytes)
             DSPAPOS: 0x00000000 (0, 0)
            DSPASIZE: 0x00000000 (1, 1)
            DSPABASE: 0x00000000
            DSPASURF: 0x08a7f000
         DSPATILEOFF: 0x00000000
           PIPEACONF: 0xc0000000 (enabled, active)
            PIPEASRC: 0x068f0419 (1680, 1050)
...
FENCE START 9: 0x08a7f0dd ( enabled, X tile walk, 7040 pitch, 0x08a7f000 start)
FENCE END 9: 0x0927e000 (                                   0x0927e000 end)

corrupted config:
            DSPACNTR: 0xd8000400 (enabled, pipe A)
          DSPASTRIDE: 0x00001c00 (7168 bytes)
             DSPAPOS: 0x00000000 (0, 0)
            DSPASIZE: 0x00000000 (1, 1)
            DSPABASE: 0x00000000
            DSPASURF: 0x077d3000
         DSPATILEOFF: 0x00000000
           PIPEACONF: 0xc0000000 (enabled, active)
            PIPEASRC: 0x068f0419 (1680, 1050)
...
FENCE START 5: 0x077d30dd ( enabled, X tile walk, 7040 pitch, 0x077d3000 start)
FENCE END 5: 0x07fd2000 (                                   0x07fd2000 end)

So the tiling doesn't match the scanout for either configuration! But otherwise the registers match, so it's probably userspace being confused. The only time when the fence is used would be during readback [ignoring FBC] so perhaps during modeswitch we decouple the old fb, readback the contents and blit into the new fb. When grabbing the screenshot we readback the contents using the same stride so everything appears fine... My conclusion is that the ddx feeds a different stride into the fb config than we use for the pixmap.

Till can you also upload Xorg.log? The driver should be printing out the framebuffer sizes and pitches - that would seem relevant here.

Created attachment 36281 [details]
screen corruption at 1680x1050 (--orientation left)

Created attachment 36282 [details]
screen corruption at 800x600 (--orientation left)

Created attachment 36283 [details]
Xorg.0.log

Hi Chris,

thanks for looking into this!

Can you tell me something about the mode ordering given in `xrandr`?
A `xrandr --output DVI1 --auto` always defaults to the resolution of 1280x1024. While this is not really a big issue, I'm puzzled why the modes are not sorted in a descending way, so that it defaults to the native panel resolution.

I am not totally conversantin intricacies of xrandr, I'll take a lot though. One snippet from Xorg.log:

[ 91895.579] (II) intel(0): Using user preference for initial modes
[ 91895.579] (II) intel(0): Output DVI1 using initial mode 1280x1024

suggests that there might be something in your /etc/x11/xorg.conf worth checking.

The staircase effect in the screenshots is a classic example of an incorrect stride, thanks! However, the driver really does believe that it is using a pitch of 7168 throughout, so how we requested a tiling with only a 7040 pitch is an interesting mystery...

* finds bug in intel_reg_dump not writing out the correct value of the fence pitch.

Back to square one. So it appears that the fence register is consistent with the tiling and stride used by the pixmap. Maybe it is not the classic staircase I so brazenly pronounced. Time to rethink.

If there's anything else you want me to test, just let me know.

Btw, you were completely right.
There were some predefined modes in my xorg.conf.
Thanks, my bad. Fixed that now. 

This is not related to the tiling issue - it's still there.
(if that question may arise)

I gave in and tried rotating my display. Didn't see the tiling corruption at 1920x1080, but I did see some rendering errors that for the time being I am choosing to ignore. ;-)

Well that was fun. Bingo at 800x600.

It was just a misuse of stride in the ddx. Trust thy instincts!

commit a25573d5c47ebea34c076075e1993233d7db2b4f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jun 15 20:26:19 2010 +0100

    drmmode: Use the tiled stride for the rotated pixmap.
    
    After d41684d5459 we now allocate all framebuffers as tiled bo, and so
    we must be careful to use the appropriate stride as returned from the
    allocation, instead of assuming that it is just an aligned width.
    
    Fixes:
    
      Bug 28461 - screen rotation results in corrupted output.
      https://bugs.freedesktop.org/show_bug.cgi?id=28461
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reported-by: Till Matthiesen <entropy@everymail.net>

(In reply to comment #17)
> I gave in and tried rotating my display. Didn't see the tiling corruption at
> 1920x1080, but I did see some rendering errors that for the time being I am
> choosing to ignore. ;-)

Hi Chris,

thanks for fixing this bug.

Concerning the misrenderings, were you facing this?
https://bugs.freedesktop.org/show_bug.cgi?id=28572