it didn't destroy the frontbuffer tracking with x running... fb_sync wasn't being called... but it indeed destroyed with igt So I agree this is not the solution to go with...
I'm going to check dirty callback... thanks for the suggestion... On Mon, Jun 22, 2015 at 6:56 AM Daniel Vetter <dan...@ffwll.ch> wrote: > On Thu, Jun 18, 2015 at 11:43:25AM -0700, Rodrigo Vivi wrote: > > @@ -259,6 +269,15 @@ void intel_frontbuffer_flip_complete(struct > drm_device *dev, > > struct drm_i915_private *dev_priv = dev->dev_private; > > > > mutex_lock(&dev_priv->fb_tracking.lock); > > + > > + /* > > + * Let's assume that if this asynchronous flip happened > > + * FBDEV might not be in use anymore. > > + * If this is not the case fb_sync will happen on next > > + * frontbuffer touch and invalidate bits again > > + */ > > + dev_priv->fb_tracking.fbdev_running = false; > > This pretty much destroys frontbuffer tracking for everyone if they boot > up with fbdev. > > Since this seems to be epic fun indeed I think what we need to do is: > - Fill out the ->dirty callback. > - Extend the drm fbdev helpers to call ->dirty at all suitable places if > needed. > > For an example of how to do this all see udl/udl_fb.c. Imo a good patch > would be to replace all the udl special casing with the new fbdev helpers, > just as a demonstration patch. i915 isn't the only driver where every > frontbuffer change must involve some manual driver action, there's no > reason we need to roll our own solution. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
