[Bug 94901] New: Display corruption due to deferred fbcon pixmap pitch calculation in radeon_set_pixmap_bo

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94901

            Bug ID: 94901
           Summary: Display corruption due to deferred fbcon pixmap pitch
                    calculation in radeon_set_pixmap_bo
           Product: xorg
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/Radeon
          Assignee: xorg-driver-ati at lists.x.org
          Reporter: jpsinthemix at verizon.net
        QA Contact: xorg-team at lists.x.org

Created attachment 122874
  --> https://bugs.freedesktop.org/attachment.cgi?id=122874&action=edit
Xorg.0.log

Hi,

I have the following (rather old) system:

Lenovo Thinkpad T60 with AMD/ATI RV515/M54 [Mobility Radeon X1400] graphics
x86_64-pc-linux-gnu, linux-4.5.0, xorg-server.1.18.3


With xf86-video-ati-7.7.0, on boot into a graphical kde session, I'm getting
display distortion on the tty1 console just as the display manager sddm begins
to start X. It is quite fleeting so I don't have a screenshot but its as if
successive scan lines start with a rapidly increasing offset from the left
stretching text and images to illegibility. A moment later the sddm login
screen displays and all is well, and the kde session appears to be unaffected.
I've attached an Xorg.0.log as well.

The issue is not present in xf86-video-ati-7.6.1. Bisecting from 7.6.1 to
7.7.0, I've determined that the problem is caused by the commit

===
https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=83734317e6bdaeebb4462a63f541e73a1d7c2f77

Update pixmap pitch in radeon_set_pixmap_bo
Stop second guessing it in drmmode_crtc_scanout_create.

Fixes display corruption in some cases with TearFree enabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94751

Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
===,

and in particular, by the changes in src/drmmode_display.c on lines 97,112, and
401.

Adding some debug printout at line 401, immediately after the
drmmode_create_bo_pixmap() call, I get

fbcon->width: 1680, fbcon->height: 1050 fbcon->depth: 24, fbcon->bpp: 32
fbcon->pitch: 6912
   pixmap->devKind: 6720 pixmap->drawable.bitsPerPixel: 32

So, it looks like xorg-server is computing pitch (pixmap->devKind) differently
from how it was
computed for fbcon.

It would seem that this could be a problem in xorg-server rather than
xf86-video-ati-7.7.0, but
I'm not sure.

The (possibly) relevant code path in from the *pScreen->ModifyPixmapHeader()
call w/pitch=-1 in xorg-server is

xorg-server-1.18.3/fb/fb24_32.c
524 Bool
525 fb24_32ModifyPixmapHeader(PixmapPtr pPixmap,
526                           int width,
527                           int height,
528                           int depth,
529                           int bitsPerPixel, int devKind, void *pPixData)
530 {
531     int bpp, w;
532
533     if (!pPixmap)
534         return FALSE;
535     bpp = bitsPerPixel;
536     if (bpp <= 0)
537         bpp = pPixmap->drawable.bitsPerPixel;
538     if (bpp == 24) {
539         if (devKind < 0) {
540             w = width;
541             if (w <= 0)
542                 w = pPixmap->drawable.width;
543             devKind = BitmapBytePad(w * 24);
544         }
545     }
546     return miModifyPixmapHeader(pPixmap, width, height, depth,
bitsPerPixel,
547                                 devKind, pPixData);

xorg-server-1.18.3/mi/miscrinit.c
105          * CAVEAT:  Non-SI DDXen may use devKind and devPrivate fields for
106          *          other purposes.
107          */
108         if (devKind > 0)
109             pPixmap->devKind = devKind;
110         else if ((devKind < 0) && ((width > 0) || (depth > 0)))
111             pPixmap->devKind = PixmapBytePad(pPixmap->drawable.width,
112                                              pPixmap->drawable.depth);


xorg-server-1.18.3/include/servermd.h
108 /* The only portable way to get the bpp from the depth is to look it up */
109 #define BitsPerPixel(d) (PixmapWidthPaddingInfo[d].bitsPerPixel)
110
111 #define PixmapWidthInPadUnits(w, d) \
112     (PixmapWidthPaddingInfo[d].notPower2 ? \
113     (((int)(w) * PixmapWidthPaddingInfo[d].bytesPerPixel +  \
114                  PixmapWidthPaddingInfo[d].bytesPerPixel) >> \
115         PixmapWidthPaddingInfo[d].padBytesLog2) : \
116     ((int)((w) + PixmapWidthPaddingInfo[d].padRoundUp) >> \
117         PixmapWidthPaddingInfo[d].padPixelsLog2))
118
119 /*
120  *      Return the number of bytes to which a scanline of the given
121  * depth and width will be padded.
122  */
123 #define PixmapBytePad(w, d) \
124     (PixmapWidthInPadUnits(w, d) << PixmapWidthPaddingInfo[d].padBytesLog2)
125
126 #define BitmapBytePad(w) \
127     (((int)((w) + BITMAP_SCANLINE_PAD - 1) >> LOG2_BITMAP_PAD) <<
LOG2_BYTES_PER_SCANLINE_PAD)
128
129 #endif                          /* SERVERMD_H */

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-driver-ati/attachments/20160411/59bebeeb/attachment-0001.html>