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 <daniel@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
