[BUG, bisect] drm/i915: mouse pointer lags and overshoots

[BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Jeremiah Mahler]

Matt, all,

Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
very unusual way, as if it has a lot of inertia.  It will lag behind and
then overshoot the expected position.

I reproduced this bug on all my machines which use the drm/i915 drivers
and it affects all forms of mouse pointers including both touchpads and
usb mice.  The patch is present in linux-next 20150116.

  commit ea2c67bb4affa84080c616920f3899f123786e56
  Author: Matt Roper <matthew.d.roper@intel.com>
  Date:   Tue Dec 23 10:41:52 2014 -0800
  
      drm/i915: Move to atomic plane helpers (v9)
      
      Switch plane handling to use the atomic plane helpers.  This means that
      rather than provide our own implementations of .update_plane() and
      .disable_plane(), we expose the lower-level check/prepare/commit/cleanup
      entrypoints and let the DRM core implement update/disable for us using
      those entrypoints.
      
      The other main change that falls out of this patch is that our
      drm_plane's will now always have a valid plane->state that contains the
      relevant plane state (initial state is allocated at plane creation).
      The base drm_plane_state pointed to holds the requested source/dest
      coordinates, and the subclassed intel_plane_state holds the adjusted
      values that our driver actually uses.
      
      v2:
       - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel)
       - Fix a copy/paste comment mistake (Bob)
      
      v3:
       - Use prepare/cleanup functions that we've already factored out
       - Use newly refactored pre_commit/commit/post_commit to avoid sleeping
         during vblank evasion
      
      v4:
       - Rebase to latest di-nightly requires adding an 'old_state' parameter
         to atomic_update;
      
      v5:
       - Must have botched a rebase somewhere and lost some work.  Restore
         state 'dirty' flag to let begin/end code know which planes to
         run the pre_commit/post_commit hooks for.  This would have actually
         shown up as broken in the next commit rather than this one.
      
      v6:
       - Squash kerneldoc patch into this one.
       - Previous patches have now already taken care of most of the
         infrastructure that used to be in this patch.  All we're adding here
         now is some thin wrappers.
      
      v7:
       - Check return of intel_plane_duplicate_state() for allocation
         failures.
      
      v8:
       - Drop unused drm_plane_state -> intel_plane_state cast.  (Ander)
       - Squash in actual transition to plane helpers.  Significant
         refactoring earlier in the patchset has made the combined
         prep+transition much easier to swallow than it was in earlier
         iterations. (Ander)
      
      v9:
       - s/track_fbs/disabled_planes/ in the atomic crtc flags.  The only fb's
         we need to update frontbuffer tracking for are those on a plane about
         to be disabled (since the atomic helpers never call prepare_fb() when
         disabling a plane), so the new name more accurately describes what
         we're actually tracking.
      
      Testcase: igt/kms_plane
      Testcase: igt/kms_universal_plane
      Testcase: igt/kms_cursor_crc
      Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
      Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

-- 
- Jeremiah Mahler

[BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Andrey Skvortsov]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

Hi,

Since next-20150113 appears problem with very slow mouse cursor. This
makes desktop almost unusable. I've just bisected the problem to the same
commit ea2c67bb4affa drm/i915: Move to atomic plane helpers (v9), as
Jeremiah did.

I want just confirm that problem too.

-- 
Best regards,
Andrey Skvortsov

Secure e-mail with gnupg: See http://www.gnupg.org/
PGP Key ID: 0x57A3AEAD



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Ville Syrjälä]

On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> Matt, all,
> 
> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> very unusual way, as if it has a lot of inertia.  It will lag behind and
> then overshoot the expected position.
> 
> I reproduced this bug on all my machines which use the drm/i915 drivers
> and it affects all forms of mouse pointers including both touchpads and
> usb mice.  The patch is present in linux-next 20150116.
> 
>   commit ea2c67bb4affa84080c616920f3899f123786e56
>   Author: Matt Roper <matthew.d.roper@intel.com>
>   Date:   Tue Dec 23 10:41:52 2014 -0800
>   
>       drm/i915: Move to atomic plane helpers (v9)

I guess this is caused by the atomic code refusing to update the plane
more than once per vrefresh. So we need to allow the fps>vrefresh rate
case to remove the regression.

The old cursor code had basically a gross hack to allow this. It just
unpinned the old fb before the display engine was done with it, and
_after_ unpinning it flipped to the new buffer (with the obvious extra
delay of the flip happening on the next vblank). So there was no
guarantee the old buffer was still around (or had the correct content)
while the display engine was still scanning it out. So to fix this
properly we need a vblank worker of some sort.

The other issues we nee to know which fb is being scanned out at which
point to unpin the correct old buffer. For that we can use the hardware
frame counter. We could use some other mechanims too (SURFLIVE, flip
counter etc.) but the frame counter is the most ubiqitious method we
have.

The one extra problem is gen2 doesn't have even the frame counter, so
some extra care would be needed there. I'm thinking for gen2 we might
allow the driver to call into the vblank core code to update the cooked
counter at any time based on the scanline counter and monotonic timestamp.
That combined with the vblank evade mechanism should make reasonably sure
we have an up to date notion of which frame is currently getting scanned
out.

We need the extra call into the vblank core since just after the vblank
start, the vblank interrupt handler may not have executed yet (especially
since gen2 vblank irq fires actually at the frame start which is a delayed
version of the vblank start, even though the flip happes at vblank start).
So we need an explicit call to make sure the cooked counter is already
updated before the irq handler has executed. I have some changes lined
up for the vblank code which I think could help make sure he extra call
won't increment the counter spuriously, but I have to clean those up a
bit before sending them out.

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Daniel Vetter]

On 19/01/2015 10:08, Ville Syrjälä wrote:
> On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
>> Matt, all,
>>
>> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
>> very unusual way, as if it has a lot of inertia.  It will lag behind and
>> then overshoot the expected position.
>>
>> I reproduced this bug on all my machines which use the drm/i915 drivers
>> and it affects all forms of mouse pointers including both touchpads and
>> usb mice.  The patch is present in linux-next 20150116.
>>
>>    commit ea2c67bb4affa84080c616920f3899f123786e56
>>    Author: Matt Roper <matthew.d.roper@intel.com>
>>    Date:   Tue Dec 23 10:41:52 2014 -0800
>>    
>>        drm/i915: Move to atomic plane helpers (v9)
> I guess this is caused by the atomic code refusing to update the plane
> more than once per vrefresh. So we need to allow the fps>vrefresh rate
> case to remove the regression.
>
> The old cursor code had basically a gross hack to allow this. It just
> unpinned the old fb before the display engine was done with it, and
> _after_ unpinning it flipped to the new buffer (with the obvious extra
> delay of the flip happening on the next vblank). So there was no
> guarantee the old buffer was still around (or had the correct content)
> while the display engine was still scanning it out. So to fix this
> properly we need a vblank worker of some sort.
>
> The other issues we nee to know which fb is being scanned out at which
> point to unpin the correct old buffer. For that we can use the hardware
> frame counter. We could use some other mechanims too (SURFLIVE, flip
> counter etc.) but the frame counter is the most ubiqitious method we
> have.
>
> The one extra problem is gen2 doesn't have even the frame counter, so
> some extra care would be needed there. I'm thinking for gen2 we might
> allow the driver to call into the vblank core code to update the cooked
> counter at any time based on the scanline counter and monotonic timestamp.
> That combined with the vblank evade mechanism should make reasonably sure
> we have an up to date notion of which frame is currently getting scanned
> out.
>
> We need the extra call into the vblank core since just after the vblank
> start, the vblank interrupt handler may not have executed yet (especially
> since gen2 vblank irq fires actually at the frame start which is a delayed
> version of the vblank start, even though the flip happes at vblank start).
> So we need an explicit call to make sure the cooked counter is already
> updated before the irq handler has executed. I have some changes lined
> up for the vblank code which I think could help make sure he extra call
> won't increment the counter spuriously, but I have to clean those up a
> bit before sending them out.
>
There's also an issue in (most) X drivers which exaberates this issues: 
When changing the cursor buffer the X cursor code does a a) disable 
cursor b) update cursor image c) enable cursor cycle. With latest 
upstream we /should/ be able to not block for just moving the cursor 
though when nothing crazy happens. Checking for that would be good.

For the real thing: Rob Clark also noticed this on msm with his atomic, 
I think we need a hint flag (only used internally) so that the 
legacy2atomic helpers and the driver core can correctly pass around 
semantics and we could recover the optimization. As long as we don't 
allow this hint flag to be set by userspace we could just completely 
drop the vblank wait - that would be buggy, but so is the old legacy 
implementation.
-Daniel
Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: Badenerstrasse 549, 8048 Zurich, Switzerland

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Chris Wilson]

On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> There's also an issue in (most) X drivers which exaberates this
> issues: When changing the cursor buffer the X cursor code does a a)
> disable cursor b) update cursor image c) enable cursor cycle.

Notably not -intel on which the bug has been observed. And more
importantly, the slow downs don't seem to correlate with cursor change,
just cursor movement.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Matt Roper]

On Mon, Jan 19, 2015 at 11:04:04AM +0000, Chris Wilson wrote:
> On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > There's also an issue in (most) X drivers which exaberates this
> > issues: When changing the cursor buffer the X cursor code does a a)
> > disable cursor b) update cursor image c) enable cursor cycle.
> 
> Notably not -intel on which the bug has been observed. And more
> importantly, the slow downs don't seem to correlate with cursor change,
> just cursor movement.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

It seems that the simple fix for this case (movement only) is to just
skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in
the transitional plane helper when newfb == oldfb.  I just posted a
small patch that makes that change (and solves the cursor lag for me).

This won't solve the case if userspace uses a different framebuffer for
each update (while trying to update faster than the refresh rate).  Is
there any existing userspace that behaves this way that we can test
with?


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Chris Wilson]

On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> On Mon, Jan 19, 2015 at 11:04:04AM +0000, Chris Wilson wrote:
> > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > There's also an issue in (most) X drivers which exaberates this
> > > issues: When changing the cursor buffer the X cursor code does a a)
> > > disable cursor b) update cursor image c) enable cursor cycle.
> > 
> > Notably not -intel on which the bug has been observed. And more
> > importantly, the slow downs don't seem to correlate with cursor change,
> > just cursor movement.
> > -Chris
> > 
> > -- 
> > Chris Wilson, Intel Open Source Technology Centre
> 
> It seems that the simple fix for this case (movement only) is to just
> skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in
> the transitional plane helper when newfb == oldfb.  I just posted a
> small patch that makes that change (and solves the cursor lag for me).
> 
> This won't solve the case if userspace uses a different framebuffer for
> each update (while trying to update faster than the refresh rate).  Is
> there any existing userspace that behaves this way that we can test
> with?

-modesetting and say moving the cursor in/out of an xterm very fast. or
similarly with

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 5b45618..3873893 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -5182,7 +5182,6 @@ sna_cursors_init(ScreenPtr screen, struct sna *sna)
        cursor_info->MaxWidth = sna->cursor.max_size;
        cursor_info->MaxHeight = sna->cursor.max_size;
        cursor_info->Flags = (HARDWARE_CURSOR_TRUECOLOR_AT_8BPP |
-                             HARDWARE_CURSOR_UPDATE_UNHIDDEN |
                              HARDWARE_CURSOR_ARGB);
 
        cursor_info->RealizeCursor = sna_realize_cursor;


-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Daniel Vetter]

On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> On Mon, Jan 19, 2015 at 11:04:04AM +0000, Chris Wilson wrote:
> > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > There's also an issue in (most) X drivers which exaberates this
> > > issues: When changing the cursor buffer the X cursor code does a a)
> > > disable cursor b) update cursor image c) enable cursor cycle.
> > 
> > Notably not -intel on which the bug has been observed. And more
> > importantly, the slow downs don't seem to correlate with cursor change,
> > just cursor movement.
> > -Chris
> > 
> > -- 
> > Chris Wilson, Intel Open Source Technology Centre
> 
> It seems that the simple fix for this case (movement only) is to just
> skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in
> the transitional plane helper when newfb == oldfb.  I just posted a
> small patch that makes that change (and solves the cursor lag for me).
> 
> This won't solve the case if userspace uses a different framebuffer for
> each update (while trying to update faster than the refresh rate).  Is
> there any existing userspace that behaves this way that we can test
> with?

Hm, I've thought I've merged that patch already:

commit ab58e3384b9f9863bfd029b458ff337d381bf6d2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Nov 24 20:42:42 2014 +0100

    drm/atomic-helper: Skip vblank waits for unchanged fbs

Or is the problem here that the transitional plane helpers aren't up to
the task? If so please reference that in your patch.

And we still need a hack for the "changed fb cursor" issue, I'll whip
something up.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Jeremiah Mahler]

all,

On Tue, Jan 20, 2015 at 06:48:42AM +0100, Daniel Vetter wrote:
> On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> > On Mon, Jan 19, 2015 at 11:04:04AM +0000, Chris Wilson wrote:
> > > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > > There's also an issue in (most) X drivers which exaberates this
> > > > issues: When changing the cursor buffer the X cursor code does a a)
> > > > disable cursor b) update cursor image c) enable cursor cycle.
> > > 
> > > Notably not -intel on which the bug has been observed. And more
> > > importantly, the slow downs don't seem to correlate with cursor change,
> > > just cursor movement.
> > > -Chris
> > > 
> > > -- 
> > > Chris Wilson, Intel Open Source Technology Centre
> > 
> > It seems that the simple fix for this case (movement only) is to just
> > skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in
> > the transitional plane helper when newfb == oldfb.  I just posted a
> > small patch that makes that change (and solves the cursor lag for me).
> > 
> > This won't solve the case if userspace uses a different framebuffer for
> > each update (while trying to update faster than the refresh rate).  Is
> > there any existing userspace that behaves this way that we can test
> > with?
> 
> Hm, I've thought I've merged that patch already:
> 
> commit ab58e3384b9f9863bfd029b458ff337d381bf6d2
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Mon Nov 24 20:42:42 2014 +0100
> 
>     drm/atomic-helper: Skip vblank waits for unchanged fbs
> 
> Or is the problem here that the transitional plane helpers aren't up to
> the task? If so please reference that in your patch.
> 
> And we still need a hack for the "changed fb cursor" issue, I'll whip
> something up.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Just checking if anyone has come up with a fix.  I am still stuck at
next-20150112 because of this bug.

-- 
- Jeremiah Mahler

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Daniel Vetter]

On Fri, Jan 23, 2015 at 10:57:32PM -0800, Jeremiah Mahler wrote:
> all,
> 
> On Tue, Jan 20, 2015 at 06:48:42AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> > > On Mon, Jan 19, 2015 at 11:04:04AM +0000, Chris Wilson wrote:
> > > > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > > > There's also an issue in (most) X drivers which exaberates this
> > > > > issues: When changing the cursor buffer the X cursor code does a a)
> > > > > disable cursor b) update cursor image c) enable cursor cycle.
> > > > 
> > > > Notably not -intel on which the bug has been observed. And more
> > > > importantly, the slow downs don't seem to correlate with cursor change,
> > > > just cursor movement.
> > > > -Chris
> > > > 
> > > > -- 
> > > > Chris Wilson, Intel Open Source Technology Centre
> > > 
> > > It seems that the simple fix for this case (movement only) is to just
> > > skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in
> > > the transitional plane helper when newfb == oldfb.  I just posted a
> > > small patch that makes that change (and solves the cursor lag for me).
> > > 
> > > This won't solve the case if userspace uses a different framebuffer for
> > > each update (while trying to update faster than the refresh rate).  Is
> > > there any existing userspace that behaves this way that we can test
> > > with?
> > 
> > Hm, I've thought I've merged that patch already:
> > 
> > commit ab58e3384b9f9863bfd029b458ff337d381bf6d2
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date:   Mon Nov 24 20:42:42 2014 +0100
> > 
> >     drm/atomic-helper: Skip vblank waits for unchanged fbs
> > 
> > Or is the problem here that the transitional plane helpers aren't up to
> > the task? If so please reference that in your patch.
> > 
> > And we still need a hack for the "changed fb cursor" issue, I'll whip
> > something up.
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 
> Just checking if anyone has come up with a fix.  I am still stuck at
> next-20150112 because of this bug.

I've merged a patch from Matt Roper:

commit d99b70ce7d73d78a88311453ccdd0fa0a670dd50
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Mon Jan 19 08:31:49 2015 -0800

    drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb

that should rectify the sluggish i915 cursor. But it's in a separate topic
branch which isn't in linux-next. Should show up in drm-next next week
though.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Jeremiah Mahler]

Daniel, Matt,

On Sat, Jan 24, 2015 at 12:24:55PM +0100, Daniel Vetter wrote:
> On Fri, Jan 23, 2015 at 10:57:32PM -0800, Jeremiah Mahler wrote:
> > all,
> > 
> > On Tue, Jan 20, 2015 at 06:48:42AM +0100, Daniel Vetter wrote:
> > > On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> > > > On Mon, Jan 19, 2015 at 11:04:04AM +0000, Chris Wilson wrote:
> > > > > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
[...]
>     drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb
> 
> that should rectify the sluggish i915 cursor. But it's in a separate topic
> branch which isn't in linux-next. Should show up in drm-next next week
> though.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

I found the patch and tried it out.  It does fix the mouse pointer
problem.  Thanks for the fix.

-- 
- Jeremiah Mahler

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Ville Syrjälä]

On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> On 19/01/2015 10:08, Ville Syrjälä wrote:
> > On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> >> Matt, all,
> >>
> >> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> >> very unusual way, as if it has a lot of inertia.  It will lag behind and
> >> then overshoot the expected position.
> >>
> >> I reproduced this bug on all my machines which use the drm/i915 drivers
> >> and it affects all forms of mouse pointers including both touchpads and
> >> usb mice.  The patch is present in linux-next 20150116.
> >>
> >>    commit ea2c67bb4affa84080c616920f3899f123786e56
> >>    Author: Matt Roper <matthew.d.roper@intel.com>
> >>    Date:   Tue Dec 23 10:41:52 2014 -0800
> >>    
> >>        drm/i915: Move to atomic plane helpers (v9)
> > I guess this is caused by the atomic code refusing to update the plane
> > more than once per vrefresh. So we need to allow the fps>vrefresh rate
> > case to remove the regression.
> >
> > The old cursor code had basically a gross hack to allow this. It just
> > unpinned the old fb before the display engine was done with it, and
> > _after_ unpinning it flipped to the new buffer (with the obvious extra
> > delay of the flip happening on the next vblank). So there was no
> > guarantee the old buffer was still around (or had the correct content)
> > while the display engine was still scanning it out. So to fix this
> > properly we need a vblank worker of some sort.
> >
> > The other issues we nee to know which fb is being scanned out at which
> > point to unpin the correct old buffer. For that we can use the hardware
> > frame counter. We could use some other mechanims too (SURFLIVE, flip
> > counter etc.) but the frame counter is the most ubiqitious method we
> > have.
> >
> > The one extra problem is gen2 doesn't have even the frame counter, so
> > some extra care would be needed there. I'm thinking for gen2 we might
> > allow the driver to call into the vblank core code to update the cooked
> > counter at any time based on the scanline counter and monotonic timestamp.
> > That combined with the vblank evade mechanism should make reasonably sure
> > we have an up to date notion of which frame is currently getting scanned
> > out.
> >
> > We need the extra call into the vblank core since just after the vblank
> > start, the vblank interrupt handler may not have executed yet (especially
> > since gen2 vblank irq fires actually at the frame start which is a delayed
> > version of the vblank start, even though the flip happes at vblank start).
> > So we need an explicit call to make sure the cooked counter is already
> > updated before the irq handler has executed. I have some changes lined
> > up for the vblank code which I think could help make sure he extra call
> > won't increment the counter spuriously, but I have to clean those up a
> > bit before sending them out.
> >
> There's also an issue in (most) X drivers which exaberates this issues: 
> When changing the cursor buffer the X cursor code does a a) disable 
> cursor b) update cursor image c) enable cursor cycle. With latest 
> upstream we /should/ be able to not block for just moving the cursor 
> though when nothing crazy happens. Checking for that would be good.
> 
> For the real thing: Rob Clark also noticed this on msm with his atomic, 
> I think we need a hint flag (only used internally) so that the 
> legacy2atomic helpers and the driver core can correctly pass around 
> semantics and we could recover the optimization. As long as we don't 
> allow this hint flag to be set by userspace we could just completely 
> drop the vblank wait - that would be buggy, but so is the old legacy 
> implementation.

Yeah, I suppose some kind of quick kludge to restore the old behaviour
would an acceptable short term solution. And as long as it's not visible
to the outside world, we can replace it anytime with a more robust
solution.

-- 
Ville Syrjälä
Intel OTC