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

[Chris Wilson]

On Thu, Sep 25, 2014 at 03:16:23PM +0200, Egbert Eich wrote:
> 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?

Oh, it fails to test for scanout bo, right. That's a nasty little corner
case that only befalls a linear scanout.

> 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.

Good to know, thanks
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre