[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 01:23:26PM +0200, Egbert Eich wrote:
 > > Chris Wilson writes:
 > >  > On Wed, Sep 24, 2014 at 12:34:29PM +0200, Egbert Eich wrote:
 > >  > > 
 > >  > > For panning one needs to be able to draw into the screen pixmap outside 
 > >  > > of the area exposed by the crtc.
 > >  > 
 > >  > Note that the screen pixmap still exists and is drawn into by the
 > >  > clients. What should happen with the panning is that the CRTC is updated
 > >  > through set_mode_major which invalidates the new CRTC location in the big
 > >  > screen Pixmap and the contents copied during the next shadow update.
 > >  > 
 > >  > That's the theory at least...
 > > 
 > > Ok, so this isn't working. I will look into this as it's easy for me
 > > to trigger this situation.
 > 
 > Are you using an OpenGL compositor? So far bare X, awesome, dwm,
 > enlightenment and kwin/xrender behave correctly. But gnome-shell and
 > kwin/gl are broken, which is not an issue with the ddx.
 > -Chris

With that patch from me which you accepted, yes, but even without it, 
a fallback should be used but this doesn't work.
I found this:
In sna_pixmap_move_to_gpu() you move a CPU bo to the GPU if available
and feasable. Shouldn't you check for the proper pitch alignment as well?
Without it, use_shadow() fails in sna_crtc_attach(), thus fb_get() is
called for a bo that was previously created for the cpu which may not
be what is expected by the GPU.
Quickly hacking in a test for 64bit alignment (which isn't correct for
all use cases) fixes the panning issue for me.


Cheers,
	Egbert.