From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: KMS cursor BO semantics Date: Sat, 5 Nov 2011 17:10:34 +0100 Message-ID: <20111105161034.GA2942@phenom.ffwll.local> References: <4EB3D3BF.70909@vmware.com> <20111104153412.GB2933@phenom.ffwll.local> <4EB4676E.7090006@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com [209.85.161.49]) by gabe.freedesktop.org (Postfix) with ESMTP id 2AEC49F381 for ; Sat, 5 Nov 2011 09:09:44 -0700 (PDT) Received: by faaq17 with SMTP id q17so4789267faa.36 for ; Sat, 05 Nov 2011 09:09:44 -0700 (PDT) Content-Disposition: inline In-Reply-To: <4EB4676E.7090006@vmware.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Thomas Hellstrom Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: > I'm not sure whether / how you handle the case of hardware render to > cursor surfaces on i915, but it seems to me like if a lot of drivers > need to implement driver specific "tricks" to meet the semantics of > a generic interface, we should perhaps consider specifying those > semantics in a way that helps avoid driver-specific workarounds? We don't handle really hanlde rendering to cursor objects. I think the "require a set_cursor after every cursor bo change" semantic is good, I've just feared that when only vmgfx needs this, no generic kms user will actually implement it. But nouveau seems to require this too, so I think at least for this case reality (and generic kms clients) will play along. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48