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 11:08:47 +0200 Message-ID: <20150119090847.GQ10649@intel.com> References: <20150117100635.GA1281@hudson.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20150117100635.GA1281@hudson.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Jeremiah Mahler , Matt Roper , Daniel Vetter , 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 List-Id: dri-devel@lists.freedesktop.org T24gU2F0LCBKYW4gMTcsIDIwMTUgYXQgMDI6MDY6MzVBTSAtMDgwMCwgSmVyZW1pYWggTWFobGVy IHdyb3RlOgo+IE1hdHQsIGFsbCwKPiAKPiBDb21taXQgZWEyYzY3YmI0YWZmIGludHJvZHVjZXMg YSBidWcgd2hpY2ggY2F1c2VzIHRoZSBtb3VzZSB0byBtb3ZlIGluIGEKPiB2ZXJ5IHVudXN1YWwg d2F5LCBhcyBpZiBpdCBoYXMgYSBsb3Qgb2YgaW5lcnRpYS4gIEl0IHdpbGwgbGFnIGJlaGluZCBh bmQKPiB0aGVuIG92ZXJzaG9vdCB0aGUgZXhwZWN0ZWQgcG9zaXRpb24uCj4gCj4gSSByZXByb2R1 Y2VkIHRoaXMgYnVnIG9uIGFsbCBteSBtYWNoaW5lcyB3aGljaCB1c2UgdGhlIGRybS9pOTE1IGRy aXZlcnMKPiBhbmQgaXQgYWZmZWN0cyBhbGwgZm9ybXMgb2YgbW91c2UgcG9pbnRlcnMgaW5jbHVk aW5nIGJvdGggdG91Y2hwYWRzIGFuZAo+IHVzYiBtaWNlLiAgVGhlIHBhdGNoIGlzIHByZXNlbnQg aW4gbGludXgtbmV4dCAyMDE1MDExNi4KPiAKPiAgIGNvbW1pdCBlYTJjNjdiYjRhZmZhODQwODBj NjE2OTIwZjM4OTlmMTIzNzg2ZTU2Cj4gICBBdXRob3I6IE1hdHQgUm9wZXIgPG1hdHRoZXcuZC5y b3BlckBpbnRlbC5jb20+Cj4gICBEYXRlOiAgIFR1ZSBEZWMgMjMgMTA6NDE6NTIgMjAxNCAtMDgw MAo+ICAgCj4gICAgICAgZHJtL2k5MTU6IE1vdmUgdG8gYXRvbWljIHBsYW5lIGhlbHBlcnMgKHY5 KQoKSSBndWVzcyB0aGlzIGlzIGNhdXNlZCBieSB0aGUgYXRvbWljIGNvZGUgcmVmdXNpbmcgdG8g dXBkYXRlIHRoZSBwbGFuZQptb3JlIHRoYW4gb25jZSBwZXIgdnJlZnJlc2guIFNvIHdlIG5lZWQg dG8gYWxsb3cgdGhlIGZwcz52cmVmcmVzaCByYXRlCmNhc2UgdG8gcmVtb3ZlIHRoZSByZWdyZXNz aW9uLgoKVGhlIG9sZCBjdXJzb3IgY29kZSBoYWQgYmFzaWNhbGx5IGEgZ3Jvc3MgaGFjayB0byBh bGxvdyB0aGlzLiBJdCBqdXN0CnVucGlubmVkIHRoZSBvbGQgZmIgYmVmb3JlIHRoZSBkaXNwbGF5 IGVuZ2luZSB3YXMgZG9uZSB3aXRoIGl0LCBhbmQKX2FmdGVyXyB1bnBpbm5pbmcgaXQgZmxpcHBl ZCB0byB0aGUgbmV3IGJ1ZmZlciAod2l0aCB0aGUgb2J2aW91cyBleHRyYQpkZWxheSBvZiB0aGUg ZmxpcCBoYXBwZW5pbmcgb24gdGhlIG5leHQgdmJsYW5rKS4gU28gdGhlcmUgd2FzIG5vCmd1YXJh bnRlZSB0aGUgb2xkIGJ1ZmZlciB3YXMgc3RpbGwgYXJvdW5kIChvciBoYWQgdGhlIGNvcnJlY3Qg Y29udGVudCkKd2hpbGUgdGhlIGRpc3BsYXkgZW5naW5lIHdhcyBzdGlsbCBzY2FubmluZyBpdCBv dXQuIFNvIHRvIGZpeCB0aGlzCnByb3Blcmx5IHdlIG5lZWQgYSB2Ymxhbmsgd29ya2VyIG9mIHNv bWUgc29ydC4KClRoZSBvdGhlciBpc3N1ZXMgd2UgbmVlIHRvIGtub3cgd2hpY2ggZmIgaXMgYmVp bmcgc2Nhbm5lZCBvdXQgYXQgd2hpY2gKcG9pbnQgdG8gdW5waW4gdGhlIGNvcnJlY3Qgb2xkIGJ1 ZmZlci4gRm9yIHRoYXQgd2UgY2FuIHVzZSB0aGUgaGFyZHdhcmUKZnJhbWUgY291bnRlci4gV2Ug Y291bGQgdXNlIHNvbWUgb3RoZXIgbWVjaGFuaW1zIHRvbyAoU1VSRkxJVkUsIGZsaXAKY291bnRl ciBldGMuKSBidXQgdGhlIGZyYW1lIGNvdW50ZXIgaXMgdGhlIG1vc3QgdWJpcWl0aW91cyBtZXRo b2Qgd2UKaGF2ZS4KClRoZSBvbmUgZXh0cmEgcHJvYmxlbSBpcyBnZW4yIGRvZXNuJ3QgaGF2ZSBl dmVuIHRoZSBmcmFtZSBjb3VudGVyLCBzbwpzb21lIGV4dHJhIGNhcmUgd291bGQgYmUgbmVlZGVk IHRoZXJlLiBJJ20gdGhpbmtpbmcgZm9yIGdlbjIgd2UgbWlnaHQKYWxsb3cgdGhlIGRyaXZlciB0 byBjYWxsIGludG8gdGhlIHZibGFuayBjb3JlIGNvZGUgdG8gdXBkYXRlIHRoZSBjb29rZWQKY291 bnRlciBhdCBhbnkgdGltZSBiYXNlZCBvbiB0aGUgc2NhbmxpbmUgY291bnRlciBhbmQgbW9ub3Rv bmljIHRpbWVzdGFtcC4KVGhhdCBjb21iaW5lZCB3aXRoIHRoZSB2YmxhbmsgZXZhZGUgbWVjaGFu aXNtIHNob3VsZCBtYWtlIHJlYXNvbmFibHkgc3VyZQp3ZSBoYXZlIGFuIHVwIHRvIGRhdGUgbm90 aW9uIG9mIHdoaWNoIGZyYW1lIGlzIGN1cnJlbnRseSBnZXR0aW5nIHNjYW5uZWQKb3V0LgoKV2Ug bmVlZCB0aGUgZXh0cmEgY2FsbCBpbnRvIHRoZSB2YmxhbmsgY29yZSBzaW5jZSBqdXN0IGFmdGVy IHRoZSB2YmxhbmsKc3RhcnQsIHRoZSB2YmxhbmsgaW50ZXJydXB0IGhhbmRsZXIgbWF5IG5vdCBo YXZlIGV4ZWN1dGVkIHlldCAoZXNwZWNpYWxseQpzaW5jZSBnZW4yIHZibGFuayBpcnEgZmlyZXMg YWN0dWFsbHkgYXQgdGhlIGZyYW1lIHN0YXJ0IHdoaWNoIGlzIGEgZGVsYXllZAp2ZXJzaW9uIG9m IHRoZSB2Ymxhbmsgc3RhcnQsIGV2ZW4gdGhvdWdoIHRoZSBmbGlwIGhhcHBlcyBhdCB2Ymxhbmsg c3RhcnQpLgpTbyB3ZSBuZWVkIGFuIGV4cGxpY2l0IGNhbGwgdG8gbWFrZSBzdXJlIHRoZSBjb29r ZWQgY291bnRlciBpcyBhbHJlYWR5CnVwZGF0ZWQgYmVmb3JlIHRoZSBpcnEgaGFuZGxlciBoYXMg ZXhlY3V0ZWQuIEkgaGF2ZSBzb21lIGNoYW5nZXMgbGluZWQKdXAgZm9yIHRoZSB2YmxhbmsgY29k ZSB3aGljaCBJIHRoaW5rIGNvdWxkIGhlbHAgbWFrZSBzdXJlIGhlIGV4dHJhIGNhbGwKd29uJ3Qg aW5jcmVtZW50IHRoZSBjb3VudGVyIHNwdXJpb3VzbHksIGJ1dCBJIGhhdmUgdG8gY2xlYW4gdGhv c2UgdXAgYQpiaXQgYmVmb3JlIHNlbmRpbmcgdGhlbSBvdXQuCgotLSAKVmlsbGUgU3lyasOkbMOk CkludGVsIE9UQwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcK aHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVsLWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752115AbbASJIz (ORCPT ); Mon, 19 Jan 2015 04:08:55 -0500 Received: from mga02.intel.com ([134.134.136.20]:16681 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751468AbbASJIw (ORCPT ); Mon, 19 Jan 2015 04:08:52 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="442193793" Date: Mon, 19 Jan 2015 11:08:47 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Jeremiah Mahler , Matt Roper , Daniel Vetter , 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: <20150119090847.GQ10649@intel.com> References: <20150117100635.GA1281@hudson.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150117100635.GA1281@hudson.localdomain> 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 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. -- Ville Syrjälä Intel OTC