From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [BUG, bisect] drm/i915: mouse pointer lags and overshoots Date: Mon, 19 Jan 2015 13:14:00 +0200 Message-ID: <20150119111400.GR10649@intel.com> References: <20150117100635.GA1281@hudson.localdomain> <20150119090847.GQ10649@intel.com> <54BCE1BF.5050808@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <54BCE1BF.5050808@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Alex Deucher , Dave Airlie , Jeremiah Mahler List-Id: dri-devel@lists.freedesktop.org T24gTW9uLCBKYW4gMTksIDIwMTUgYXQgMTE6NTE6NDNBTSArMDEwMCwgRGFuaWVsIFZldHRlciB3 cm90ZToKPiBPbiAxOS8wMS8yMDE1IDEwOjA4LCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPiBP biBTYXQsIEphbiAxNywgMjAxNSBhdCAwMjowNjozNUFNIC0wODAwLCBKZXJlbWlhaCBNYWhsZXIg d3JvdGU6Cj4gPj4gTWF0dCwgYWxsLAo+ID4+Cj4gPj4gQ29tbWl0IGVhMmM2N2JiNGFmZiBpbnRy b2R1Y2VzIGEgYnVnIHdoaWNoIGNhdXNlcyB0aGUgbW91c2UgdG8gbW92ZSBpbiBhCj4gPj4gdmVy eSB1bnVzdWFsIHdheSwgYXMgaWYgaXQgaGFzIGEgbG90IG9mIGluZXJ0aWEuICBJdCB3aWxsIGxh ZyBiZWhpbmQgYW5kCj4gPj4gdGhlbiBvdmVyc2hvb3QgdGhlIGV4cGVjdGVkIHBvc2l0aW9uLgo+ ID4+Cj4gPj4gSSByZXByb2R1Y2VkIHRoaXMgYnVnIG9uIGFsbCBteSBtYWNoaW5lcyB3aGljaCB1 c2UgdGhlIGRybS9pOTE1IGRyaXZlcnMKPiA+PiBhbmQgaXQgYWZmZWN0cyBhbGwgZm9ybXMgb2Yg bW91c2UgcG9pbnRlcnMgaW5jbHVkaW5nIGJvdGggdG91Y2hwYWRzIGFuZAo+ID4+IHVzYiBtaWNl LiAgVGhlIHBhdGNoIGlzIHByZXNlbnQgaW4gbGludXgtbmV4dCAyMDE1MDExNi4KPiA+Pgo+ID4+ ICAgIGNvbW1pdCBlYTJjNjdiYjRhZmZhODQwODBjNjE2OTIwZjM4OTlmMTIzNzg2ZTU2Cj4gPj4g ICAgQXV0aG9yOiBNYXR0IFJvcGVyIDxtYXR0aGV3LmQucm9wZXJAaW50ZWwuY29tPgo+ID4+ICAg IERhdGU6ICAgVHVlIERlYyAyMyAxMDo0MTo1MiAyMDE0IC0wODAwCj4gPj4gICAgCj4gPj4gICAg ICAgIGRybS9pOTE1OiBNb3ZlIHRvIGF0b21pYyBwbGFuZSBoZWxwZXJzICh2OSkKPiA+IEkgZ3Vl c3MgdGhpcyBpcyBjYXVzZWQgYnkgdGhlIGF0b21pYyBjb2RlIHJlZnVzaW5nIHRvIHVwZGF0ZSB0 aGUgcGxhbmUKPiA+IG1vcmUgdGhhbiBvbmNlIHBlciB2cmVmcmVzaC4gU28gd2UgbmVlZCB0byBh bGxvdyB0aGUgZnBzPnZyZWZyZXNoIHJhdGUKPiA+IGNhc2UgdG8gcmVtb3ZlIHRoZSByZWdyZXNz aW9uLgo+ID4KPiA+IFRoZSBvbGQgY3Vyc29yIGNvZGUgaGFkIGJhc2ljYWxseSBhIGdyb3NzIGhh Y2sgdG8gYWxsb3cgdGhpcy4gSXQganVzdAo+ID4gdW5waW5uZWQgdGhlIG9sZCBmYiBiZWZvcmUg dGhlIGRpc3BsYXkgZW5naW5lIHdhcyBkb25lIHdpdGggaXQsIGFuZAo+ID4gX2FmdGVyXyB1bnBp bm5pbmcgaXQgZmxpcHBlZCB0byB0aGUgbmV3IGJ1ZmZlciAod2l0aCB0aGUgb2J2aW91cyBleHRy YQo+ID4gZGVsYXkgb2YgdGhlIGZsaXAgaGFwcGVuaW5nIG9uIHRoZSBuZXh0IHZibGFuaykuIFNv IHRoZXJlIHdhcyBubwo+ID4gZ3VhcmFudGVlIHRoZSBvbGQgYnVmZmVyIHdhcyBzdGlsbCBhcm91 bmQgKG9yIGhhZCB0aGUgY29ycmVjdCBjb250ZW50KQo+ID4gd2hpbGUgdGhlIGRpc3BsYXkgZW5n aW5lIHdhcyBzdGlsbCBzY2FubmluZyBpdCBvdXQuIFNvIHRvIGZpeCB0aGlzCj4gPiBwcm9wZXJs eSB3ZSBuZWVkIGEgdmJsYW5rIHdvcmtlciBvZiBzb21lIHNvcnQuCj4gPgo+ID4gVGhlIG90aGVy IGlzc3VlcyB3ZSBuZWUgdG8ga25vdyB3aGljaCBmYiBpcyBiZWluZyBzY2FubmVkIG91dCBhdCB3 aGljaAo+ID4gcG9pbnQgdG8gdW5waW4gdGhlIGNvcnJlY3Qgb2xkIGJ1ZmZlci4gRm9yIHRoYXQg d2UgY2FuIHVzZSB0aGUgaGFyZHdhcmUKPiA+IGZyYW1lIGNvdW50ZXIuIFdlIGNvdWxkIHVzZSBz b21lIG90aGVyIG1lY2hhbmltcyB0b28gKFNVUkZMSVZFLCBmbGlwCj4gPiBjb3VudGVyIGV0Yy4p IGJ1dCB0aGUgZnJhbWUgY291bnRlciBpcyB0aGUgbW9zdCB1YmlxaXRpb3VzIG1ldGhvZCB3ZQo+ ID4gaGF2ZS4KPiA+Cj4gPiBUaGUgb25lIGV4dHJhIHByb2JsZW0gaXMgZ2VuMiBkb2Vzbid0IGhh dmUgZXZlbiB0aGUgZnJhbWUgY291bnRlciwgc28KPiA+IHNvbWUgZXh0cmEgY2FyZSB3b3VsZCBi ZSBuZWVkZWQgdGhlcmUuIEknbSB0aGlua2luZyBmb3IgZ2VuMiB3ZSBtaWdodAo+ID4gYWxsb3cg dGhlIGRyaXZlciB0byBjYWxsIGludG8gdGhlIHZibGFuayBjb3JlIGNvZGUgdG8gdXBkYXRlIHRo ZSBjb29rZWQKPiA+IGNvdW50ZXIgYXQgYW55IHRpbWUgYmFzZWQgb24gdGhlIHNjYW5saW5lIGNv dW50ZXIgYW5kIG1vbm90b25pYyB0aW1lc3RhbXAuCj4gPiBUaGF0IGNvbWJpbmVkIHdpdGggdGhl IHZibGFuayBldmFkZSBtZWNoYW5pc20gc2hvdWxkIG1ha2UgcmVhc29uYWJseSBzdXJlCj4gPiB3 ZSBoYXZlIGFuIHVwIHRvIGRhdGUgbm90aW9uIG9mIHdoaWNoIGZyYW1lIGlzIGN1cnJlbnRseSBn ZXR0aW5nIHNjYW5uZWQKPiA+IG91dC4KPiA+Cj4gPiBXZSBuZWVkIHRoZSBleHRyYSBjYWxsIGlu dG8gdGhlIHZibGFuayBjb3JlIHNpbmNlIGp1c3QgYWZ0ZXIgdGhlIHZibGFuawo+ID4gc3RhcnQs IHRoZSB2YmxhbmsgaW50ZXJydXB0IGhhbmRsZXIgbWF5IG5vdCBoYXZlIGV4ZWN1dGVkIHlldCAo ZXNwZWNpYWxseQo+ID4gc2luY2UgZ2VuMiB2YmxhbmsgaXJxIGZpcmVzIGFjdHVhbGx5IGF0IHRo ZSBmcmFtZSBzdGFydCB3aGljaCBpcyBhIGRlbGF5ZWQKPiA+IHZlcnNpb24gb2YgdGhlIHZibGFu ayBzdGFydCwgZXZlbiB0aG91Z2ggdGhlIGZsaXAgaGFwcGVzIGF0IHZibGFuayBzdGFydCkuCj4g PiBTbyB3ZSBuZWVkIGFuIGV4cGxpY2l0IGNhbGwgdG8gbWFrZSBzdXJlIHRoZSBjb29rZWQgY291 bnRlciBpcyBhbHJlYWR5Cj4gPiB1cGRhdGVkIGJlZm9yZSB0aGUgaXJxIGhhbmRsZXIgaGFzIGV4 ZWN1dGVkLiBJIGhhdmUgc29tZSBjaGFuZ2VzIGxpbmVkCj4gPiB1cCBmb3IgdGhlIHZibGFuayBj b2RlIHdoaWNoIEkgdGhpbmsgY291bGQgaGVscCBtYWtlIHN1cmUgaGUgZXh0cmEgY2FsbAo+ID4g d29uJ3QgaW5jcmVtZW50IHRoZSBjb3VudGVyIHNwdXJpb3VzbHksIGJ1dCBJIGhhdmUgdG8gY2xl YW4gdGhvc2UgdXAgYQo+ID4gYml0IGJlZm9yZSBzZW5kaW5nIHRoZW0gb3V0Lgo+ID4KPiBUaGVy ZSdzIGFsc28gYW4gaXNzdWUgaW4gKG1vc3QpIFggZHJpdmVycyB3aGljaCBleGFiZXJhdGVzIHRo aXMgaXNzdWVzOiAKPiBXaGVuIGNoYW5naW5nIHRoZSBjdXJzb3IgYnVmZmVyIHRoZSBYIGN1cnNv ciBjb2RlIGRvZXMgYSBhKSBkaXNhYmxlIAo+IGN1cnNvciBiKSB1cGRhdGUgY3Vyc29yIGltYWdl IGMpIGVuYWJsZSBjdXJzb3IgY3ljbGUuIFdpdGggbGF0ZXN0IAo+IHVwc3RyZWFtIHdlIC9zaG91 bGQvIGJlIGFibGUgdG8gbm90IGJsb2NrIGZvciBqdXN0IG1vdmluZyB0aGUgY3Vyc29yIAo+IHRo b3VnaCB3aGVuIG5vdGhpbmcgY3JhenkgaGFwcGVucy4gQ2hlY2tpbmcgZm9yIHRoYXQgd291bGQg YmUgZ29vZC4KPiAKPiBGb3IgdGhlIHJlYWwgdGhpbmc6IFJvYiBDbGFyayBhbHNvIG5vdGljZWQg dGhpcyBvbiBtc20gd2l0aCBoaXMgYXRvbWljLCAKPiBJIHRoaW5rIHdlIG5lZWQgYSBoaW50IGZs YWcgKG9ubHkgdXNlZCBpbnRlcm5hbGx5KSBzbyB0aGF0IHRoZSAKPiBsZWdhY3kyYXRvbWljIGhl bHBlcnMgYW5kIHRoZSBkcml2ZXIgY29yZSBjYW4gY29ycmVjdGx5IHBhc3MgYXJvdW5kIAo+IHNl bWFudGljcyBhbmQgd2UgY291bGQgcmVjb3ZlciB0aGUgb3B0aW1pemF0aW9uLiBBcyBsb25nIGFz IHdlIGRvbid0IAo+IGFsbG93IHRoaXMgaGludCBmbGFnIHRvIGJlIHNldCBieSB1c2Vyc3BhY2Ug d2UgY291bGQganVzdCBjb21wbGV0ZWx5IAo+IGRyb3AgdGhlIHZibGFuayB3YWl0IC0gdGhhdCB3 b3VsZCBiZSBidWdneSwgYnV0IHNvIGlzIHRoZSBvbGQgbGVnYWN5IAo+IGltcGxlbWVudGF0aW9u LgoKWWVhaCwgSSBzdXBwb3NlIHNvbWUga2luZCBvZiBxdWljayBrbHVkZ2UgdG8gcmVzdG9yZSB0 aGUgb2xkIGJlaGF2aW91cgp3b3VsZCBhbiBhY2NlcHRhYmxlIHNob3J0IHRlcm0gc29sdXRpb24u IEFuZCBhcyBsb25nIGFzIGl0J3Mgbm90IHZpc2libGUKdG8gdGhlIG91dHNpZGUgd29ybGQsIHdl IGNhbiByZXBsYWNlIGl0IGFueXRpbWUgd2l0aCBhIG1vcmUgcm9idXN0CnNvbHV0aW9uLgoKLS0g ClZpbGxlIFN5cmrDpGzDpApJbnRlbCBPVEMKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMu ZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9pbnRlbC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751896AbbASLOH (ORCPT ); Mon, 19 Jan 2015 06:14:07 -0500 Received: from mga09.intel.com ([134.134.136.24]:40300 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751727AbbASLOG (ORCPT ); Mon, 19 Jan 2015 06:14:06 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,426,1418112000"; d="scan'208";a="664001804" Date: Mon, 19 Jan 2015 13:14:00 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Daniel Vetter Cc: Jeremiah Mahler , Matt Roper , Jani Nikula , David Airlie , Alex Deucher , Dave Airlie , Ander Conselvan de Oliveira , 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 Message-ID: <20150119111400.GR10649@intel.com> References: <20150117100635.GA1281@hudson.localdomain> <20150119090847.GQ10649@intel.com> <54BCE1BF.5050808@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54BCE1BF.5050808@intel.com> User-Agent: Mutt/1.5.22 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > >> 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