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

Egbert Eich eich at freedesktop.org
Wed Sep 24 03:34:29 PDT 2014


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.


More information about the xorg-devel mailing list