LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jeremiah Mahler <jmmahler@gmail.com>,
	Matt Roper <matthew.d.roper@intel.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	David Airlie <airlied@linux.ie>,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@redhat.com>,
	Ander Conselvan de Oliveira <conselvan2@gmail.com>,
	linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots
Date: Mon, 19 Jan 2015 11:08:47 +0200	[thread overview]
Message-ID: <20150119090847.GQ10649@intel.com> (raw)
In-Reply-To: <20150117100635.GA1281@hudson.localdomain>

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

  parent reply	other threads:[~2015-01-19  9:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-17 10:06 Jeremiah Mahler
2015-01-18 13:57 ` Andrey Skvortsov
2015-01-19  9:08 ` Ville Syrjälä [this message]
2015-01-19 10:51   ` [Intel-gfx] " Daniel Vetter
2015-01-19 11:04     ` Chris Wilson
2015-01-19 16:40       ` Matt Roper
2015-01-19 20:43         ` Chris Wilson
2015-01-20  5:48         ` Daniel Vetter
2015-01-24  6:57           ` Jeremiah Mahler
2015-01-24 11:24             ` Daniel Vetter
2015-01-24 20:27               ` Jeremiah Mahler
2015-01-19 11:14     ` Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150119090847.GQ10649@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=alexander.deucher@amd.com \
    --cc=conselvan2@gmail.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jmmahler@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.d.roper@intel.com \
    --subject='Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).