screen update problems with Intel HD 4600 + virtual screen

[Chris Wilson]

On Mon, Jun 23, 2014 at 09:49:07AM +0200, Krzysztof Halasa wrote:
> khalasa at piap.pl (Krzysztof Hałasa) writes:
> 
> > I'm having screen update problems problems with an Intel HD 4600 with
> > panning + virtual screen. Fedora 20 + updates, CPU is Core i7 4770K,
> > I'm using xrandr --output HDMI1 --panning 4096x2404. The physical screen
> > size is 1920x1200.
> > Another setup also experiencing this problem is Core i5 4200M with
> > a 1600x900 physical screen (LVDS) and (a bit larger) virtual screen
> > (again with panning).
> 
> This happens with both UXA and SNA. ATM I'm now using SNA as UXA(?) had
> some probably unrelated problems with Xvideo (non)updates.
> 
> Screen 0: minimum 320 x 200, current 4096 x 2404, maximum 32767 x 32767
> VGA1 disconnected (normal left inverted right x axis y axis)
> HDMI1 connected 4096x2404+0+0 (normal left inverted right x axis y axis)
> 518mm x 324mm panning 4096x2404+0+0
>    1920x1200     59.95*+
>    [etc.]
> DP1 disconnected (normal left inverted right x axis y axis)
> HDMI2 disconnected (normal left inverted right x axis y axis)
> HDMI3 disconnected (normal left inverted right x axis y axis)
> 
> It looks with SNA, all is good as long as the screen isn't moved
> (panned) down more than 7 pixels (i.e. the screen y offset must be 0 - 7
> and x offset doesn't matter):
> 
> switch to mode 1920x1200 at 60.0 on pipe 0 using HDMI1, position (2176, 0), rotation normal
> switch to mode 1920x1200 at 60.0 on pipe 0 using HDMI1, position (2176, 1), rotation normal
> switch to mode 1920x1200 at 60.0 on pipe 0 using HDMI1, position (2176, 2), rotation normal
> ...
> switch to mode 1920x1200 at 60.0 on pipe 0 using HDMI1, position (2176, 6), rotation normal
> switch to mode 1920x1200 at 60.0 on pipe 0 using HDMI1, position (2176, 7), rotation normal
> 
> Now I scroll down 1 pixel:
> switch to mode 1920x1200 at 60.0 on pipe 0 using HDMI1, position (2176, 8), rotation normal
> 
> and immediately screen isn't updated correctly. For example, an
> application window is created normally, but when I move it (the app
> window) down, the top part of the window, max 8 pixels, is left on the
> screen (the moved window is ok). It almost looks like the code somewhere
> adds the vertical screen offset twice.

8 is significant as it is the tile row height. The kernel tries to be
smart and extract the panning from the surface address so that we can
display a larger virtual framebuffer than the hardware can actually use.

Can you reproduce the about sequence with drm.debug=6 dmesg (i.e.
echo 6 > /sys/module/drm/parameters/debug ; xrandr --panning... ;
dmesg)?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre