From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [BUG, bisect] drm/i915: mouse pointer lags and overshoots Date: Mon, 19 Jan 2015 11:51:43 +0100 Message-ID: <54BCE1BF.5050808@intel.com> References: <20150117100635.GA1281@hudson.localdomain> <20150119090847.GQ10649@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20150119090847.GQ10649@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: =?windows-1252?Q?Ville_Syrj=E4l=E4?= , 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 List-Id: dri-devel@lists.freedesktop.org T24gMTkvMDEvMjAxNSAxMDowOCwgVmlsbGUgU3lyasOkbMOkIHdyb3RlOgo+IE9uIFNhdCwgSmFu IDE3LCAyMDE1IGF0IDAyOjA2OjM1QU0gLTA4MDAsIEplcmVtaWFoIE1haGxlciB3cm90ZToKPj4g TWF0dCwgYWxsLAo+Pgo+PiBDb21taXQgZWEyYzY3YmI0YWZmIGludHJvZHVjZXMgYSBidWcgd2hp Y2ggY2F1c2VzIHRoZSBtb3VzZSB0byBtb3ZlIGluIGEKPj4gdmVyeSB1bnVzdWFsIHdheSwgYXMg aWYgaXQgaGFzIGEgbG90IG9mIGluZXJ0aWEuICBJdCB3aWxsIGxhZyBiZWhpbmQgYW5kCj4+IHRo ZW4gb3ZlcnNob290IHRoZSBleHBlY3RlZCBwb3NpdGlvbi4KPj4KPj4gSSByZXByb2R1Y2VkIHRo aXMgYnVnIG9uIGFsbCBteSBtYWNoaW5lcyB3aGljaCB1c2UgdGhlIGRybS9pOTE1IGRyaXZlcnMK Pj4gYW5kIGl0IGFmZmVjdHMgYWxsIGZvcm1zIG9mIG1vdXNlIHBvaW50ZXJzIGluY2x1ZGluZyBi b3RoIHRvdWNocGFkcyBhbmQKPj4gdXNiIG1pY2UuICBUaGUgcGF0Y2ggaXMgcHJlc2VudCBpbiBs aW51eC1uZXh0IDIwMTUwMTE2Lgo+Pgo+PiAgICBjb21taXQgZWEyYzY3YmI0YWZmYTg0MDgwYzYx NjkyMGYzODk5ZjEyMzc4NmU1Ngo+PiAgICBBdXRob3I6IE1hdHQgUm9wZXIgPG1hdHRoZXcuZC5y b3BlckBpbnRlbC5jb20+Cj4+ICAgIERhdGU6ICAgVHVlIERlYyAyMyAxMDo0MTo1MiAyMDE0IC0w ODAwCj4+ICAgIAo+PiAgICAgICAgZHJtL2k5MTU6IE1vdmUgdG8gYXRvbWljIHBsYW5lIGhlbHBl cnMgKHY5KQo+IEkgZ3Vlc3MgdGhpcyBpcyBjYXVzZWQgYnkgdGhlIGF0b21pYyBjb2RlIHJlZnVz aW5nIHRvIHVwZGF0ZSB0aGUgcGxhbmUKPiBtb3JlIHRoYW4gb25jZSBwZXIgdnJlZnJlc2guIFNv IHdlIG5lZWQgdG8gYWxsb3cgdGhlIGZwcz52cmVmcmVzaCByYXRlCj4gY2FzZSB0byByZW1vdmUg dGhlIHJlZ3Jlc3Npb24uCj4KPiBUaGUgb2xkIGN1cnNvciBjb2RlIGhhZCBiYXNpY2FsbHkgYSBn cm9zcyBoYWNrIHRvIGFsbG93IHRoaXMuIEl0IGp1c3QKPiB1bnBpbm5lZCB0aGUgb2xkIGZiIGJl Zm9yZSB0aGUgZGlzcGxheSBlbmdpbmUgd2FzIGRvbmUgd2l0aCBpdCwgYW5kCj4gX2FmdGVyXyB1 bnBpbm5pbmcgaXQgZmxpcHBlZCB0byB0aGUgbmV3IGJ1ZmZlciAod2l0aCB0aGUgb2J2aW91cyBl eHRyYQo+IGRlbGF5IG9mIHRoZSBmbGlwIGhhcHBlbmluZyBvbiB0aGUgbmV4dCB2YmxhbmspLiBT byB0aGVyZSB3YXMgbm8KPiBndWFyYW50ZWUgdGhlIG9sZCBidWZmZXIgd2FzIHN0aWxsIGFyb3Vu ZCAob3IgaGFkIHRoZSBjb3JyZWN0IGNvbnRlbnQpCj4gd2hpbGUgdGhlIGRpc3BsYXkgZW5naW5l IHdhcyBzdGlsbCBzY2FubmluZyBpdCBvdXQuIFNvIHRvIGZpeCB0aGlzCj4gcHJvcGVybHkgd2Ug bmVlZCBhIHZibGFuayB3b3JrZXIgb2Ygc29tZSBzb3J0Lgo+Cj4gVGhlIG90aGVyIGlzc3VlcyB3 ZSBuZWUgdG8ga25vdyB3aGljaCBmYiBpcyBiZWluZyBzY2FubmVkIG91dCBhdCB3aGljaAo+IHBv aW50IHRvIHVucGluIHRoZSBjb3JyZWN0IG9sZCBidWZmZXIuIEZvciB0aGF0IHdlIGNhbiB1c2Ug dGhlIGhhcmR3YXJlCj4gZnJhbWUgY291bnRlci4gV2UgY291bGQgdXNlIHNvbWUgb3RoZXIgbWVj aGFuaW1zIHRvbyAoU1VSRkxJVkUsIGZsaXAKPiBjb3VudGVyIGV0Yy4pIGJ1dCB0aGUgZnJhbWUg Y291bnRlciBpcyB0aGUgbW9zdCB1YmlxaXRpb3VzIG1ldGhvZCB3ZQo+IGhhdmUuCj4KPiBUaGUg b25lIGV4dHJhIHByb2JsZW0gaXMgZ2VuMiBkb2Vzbid0IGhhdmUgZXZlbiB0aGUgZnJhbWUgY291 bnRlciwgc28KPiBzb21lIGV4dHJhIGNhcmUgd291bGQgYmUgbmVlZGVkIHRoZXJlLiBJJ20gdGhp bmtpbmcgZm9yIGdlbjIgd2UgbWlnaHQKPiBhbGxvdyB0aGUgZHJpdmVyIHRvIGNhbGwgaW50byB0 aGUgdmJsYW5rIGNvcmUgY29kZSB0byB1cGRhdGUgdGhlIGNvb2tlZAo+IGNvdW50ZXIgYXQgYW55 IHRpbWUgYmFzZWQgb24gdGhlIHNjYW5saW5lIGNvdW50ZXIgYW5kIG1vbm90b25pYyB0aW1lc3Rh bXAuCj4gVGhhdCBjb21iaW5lZCB3aXRoIHRoZSB2YmxhbmsgZXZhZGUgbWVjaGFuaXNtIHNob3Vs ZCBtYWtlIHJlYXNvbmFibHkgc3VyZQo+IHdlIGhhdmUgYW4gdXAgdG8gZGF0ZSBub3Rpb24gb2Yg d2hpY2ggZnJhbWUgaXMgY3VycmVudGx5IGdldHRpbmcgc2Nhbm5lZAo+IG91dC4KPgo+IFdlIG5l ZWQgdGhlIGV4dHJhIGNhbGwgaW50byB0aGUgdmJsYW5rIGNvcmUgc2luY2UganVzdCBhZnRlciB0 aGUgdmJsYW5rCj4gc3RhcnQsIHRoZSB2YmxhbmsgaW50ZXJydXB0IGhhbmRsZXIgbWF5IG5vdCBo YXZlIGV4ZWN1dGVkIHlldCAoZXNwZWNpYWxseQo+IHNpbmNlIGdlbjIgdmJsYW5rIGlycSBmaXJl cyBhY3R1YWxseSBhdCB0aGUgZnJhbWUgc3RhcnQgd2hpY2ggaXMgYSBkZWxheWVkCj4gdmVyc2lv biBvZiB0aGUgdmJsYW5rIHN0YXJ0LCBldmVuIHRob3VnaCB0aGUgZmxpcCBoYXBwZXMgYXQgdmJs YW5rIHN0YXJ0KS4KPiBTbyB3ZSBuZWVkIGFuIGV4cGxpY2l0IGNhbGwgdG8gbWFrZSBzdXJlIHRo ZSBjb29rZWQgY291bnRlciBpcyBhbHJlYWR5Cj4gdXBkYXRlZCBiZWZvcmUgdGhlIGlycSBoYW5k bGVyIGhhcyBleGVjdXRlZC4gSSBoYXZlIHNvbWUgY2hhbmdlcyBsaW5lZAo+IHVwIGZvciB0aGUg dmJsYW5rIGNvZGUgd2hpY2ggSSB0aGluayBjb3VsZCBoZWxwIG1ha2Ugc3VyZSBoZSBleHRyYSBj YWxsCj4gd29uJ3QgaW5jcmVtZW50IHRoZSBjb3VudGVyIHNwdXJpb3VzbHksIGJ1dCBJIGhhdmUg dG8gY2xlYW4gdGhvc2UgdXAgYQo+IGJpdCBiZWZvcmUgc2VuZGluZyB0aGVtIG91dC4KPgpUaGVy ZSdzIGFsc28gYW4gaXNzdWUgaW4gKG1vc3QpIFggZHJpdmVycyB3aGljaCBleGFiZXJhdGVzIHRo aXMgaXNzdWVzOiAKV2hlbiBjaGFuZ2luZyB0aGUgY3Vyc29yIGJ1ZmZlciB0aGUgWCBjdXJzb3Ig Y29kZSBkb2VzIGEgYSkgZGlzYWJsZSAKY3Vyc29yIGIpIHVwZGF0ZSBjdXJzb3IgaW1hZ2UgYykg ZW5hYmxlIGN1cnNvciBjeWNsZS4gV2l0aCBsYXRlc3QgCnVwc3RyZWFtIHdlIC9zaG91bGQvIGJl IGFibGUgdG8gbm90IGJsb2NrIGZvciBqdXN0IG1vdmluZyB0aGUgY3Vyc29yIAp0aG91Z2ggd2hl biBub3RoaW5nIGNyYXp5IGhhcHBlbnMuIENoZWNraW5nIGZvciB0aGF0IHdvdWxkIGJlIGdvb2Qu CgpGb3IgdGhlIHJlYWwgdGhpbmc6IFJvYiBDbGFyayBhbHNvIG5vdGljZWQgdGhpcyBvbiBtc20g d2l0aCBoaXMgYXRvbWljLCAKSSB0aGluayB3ZSBuZWVkIGEgaGludCBmbGFnIChvbmx5IHVzZWQg aW50ZXJuYWxseSkgc28gdGhhdCB0aGUgCmxlZ2FjeTJhdG9taWMgaGVscGVycyBhbmQgdGhlIGRy aXZlciBjb3JlIGNhbiBjb3JyZWN0bHkgcGFzcyBhcm91bmQgCnNlbWFudGljcyBhbmQgd2UgY291 bGQgcmVjb3ZlciB0aGUgb3B0aW1pemF0aW9uLiBBcyBsb25nIGFzIHdlIGRvbid0IAphbGxvdyB0 aGlzIGhpbnQgZmxhZyB0byBiZSBzZXQgYnkgdXNlcnNwYWNlIHdlIGNvdWxkIGp1c3QgY29tcGxl dGVseSAKZHJvcCB0aGUgdmJsYW5rIHdhaXQgLSB0aGF0IHdvdWxkIGJlIGJ1Z2d5LCBidXQgc28g aXMgdGhlIG9sZCBsZWdhY3kgCmltcGxlbWVudGF0aW9uLgotRGFuaWVsCkludGVsIFNlbWljb25k dWN0b3IgQUcKUmVnaXN0ZXJlZCBOby4gMDIwLjMwLjkxMy43ODYtNwpSZWdpc3RlcmVkIE9mZmlj ZTogQmFkZW5lcnN0cmFzc2UgNTQ5LCA4MDQ4IFp1cmljaCwgU3dpdHplcmxhbmQKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkludGVsLWdmeCBtYWlsaW5n IGxpc3QKSW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRl c2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752248AbbASKvv (ORCPT ); Mon, 19 Jan 2015 05:51:51 -0500 Received: from mga11.intel.com ([192.55.52.93]:40900 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751865AbbASKvs convert rfc822-to-8bit (ORCPT ); Mon, 19 Jan 2015 05:51:48 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="442221702" Message-ID: <54BCE1BF.5050808@intel.com> Date: Mon, 19 Jan 2015 11:51:43 +0100 From: Daniel Vetter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?Ville_Syrj=E4l=E4?= , 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 References: <20150117100635.GA1281@hudson.localdomain> <20150119090847.GQ10649@intel.com> In-Reply-To: <20150119090847.GQ10649@intel.com> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -Daniel Intel Semiconductor AG Registered No. 020.30.913.786-7 Registered Office: Badenerstrasse 549, 8048 Zurich, Switzerland