[PATCH driver/intel] Allow copy_front() to fail and clean up gracefully if it does

[Egbert Eich]

Chris Wilson writes:
 > On Wed, Sep 24, 2014 at 08:17:59AM +0200, Egbert Eich wrote:
 > > From: Egbert Eich <eich at suse.de>
 > > 
 > > copy_front() calls sna_pixmap_force_to_gpu() which may fail. If we pretend
 > > to have been successful and continue the caller sna_mode_resize() may finish
 > > successfully pretending a mode change has succeeded which might leave a mode
 > > behind which is unusable.
 > 
 > Show me the actual bug. If the copy fails, the new framebuffer contents
 > are just left uninitialised (normal X behaviour) until they get
 > "immediately" redrawn. The subsequent modeset does not depend upon the screen
 > Pixmap fitting into GPU memory, but that it can fit individual CRTC into
 > the GTT.

Then the mode should have failed somewhere else maybe.

The underlying issue of the problem was fixed by the other
patch I have sent today. This problem caused kgem_surface_size() 
to return NULL and thus kgem_create_2d() and ulitmately 
sna_pixmap_force_to_gpu() to fail.
With the the other fix applied kgem_surface_size() doesn't
fail any longer for my test case - still it may fail for other 
reasons.

Here is the test scenario:

Pineview Chipset, start a bare X server (without the other patch applied
to the driver), start xterm on it.

On my system 'xrandr -q' gives:

Screen 0: minimum 8 x 8, current 1366 x 768, maximum 32767 x 32767
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 222mm x 125mm
   1366x768       60.0*+
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

now run 'xrandr --output LVDS1 --panning 3048x768' (or whatever
other output it uses).

Without the other patch applied kgem_surface_size() fails, without
*both* patches applied the mode set succeeds and 'xandr -q' now gives:

Screen 0: minimum 8 x 8, current 3048 x 768, maximum 32767 x 32767
LVDS1 connected 3048x768+0+0 (normal left inverted right x axis y axis) 222mm x 125mm panning 3048x768+0+0
   1366x768       60.0*+
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Observation 1:
Screen doesn't pan: when moving the cursor to the right edge,
screen and cursor become out of sync, screen content doesnt get
update ie. starting a new application (like xclock) succeeds but
nothing is drawn).

Observation 2:
Terminating xterm makes the server reset which fails with

intel(0): [intel] Failed to allocate video resources for front buffer 3048x768 at depth 24

in sna_create_screen_resources() due to sna_pixmap_force_to_gpu()
failing. The reason for the failure is the same as described above.

As I said: these failures go away with the other patch I posted today
and which you OKed and the code in this patch is no longer triggered.
Still there are other conditions under which kgem_surface_size() may 
return 0. 
For panning one needs to be able to draw into the screen pixmap outside 
of the area exposed by the crtc.

Cheers,
	Egbert.