From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: KMS cursor BO semantics Date: Mon, 07 Nov 2011 11:26:18 +0100 Message-ID: <4EB7B24A.2080808@vmware.com> References: <4EB3D3BF.70909@vmware.com> <20111104153412.GB2933@phenom.ffwll.local> <4EB4676E.7090006@vmware.com> <20111105161034.GA2942@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [65.115.85.73]) by gabe.freedesktop.org (Postfix) with ESMTP id 167DD9E961 for ; Mon, 7 Nov 2011 02:28:51 -0800 (PST) In-Reply-To: <20111105161034.GA2942@phenom.ffwll.local> 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: Daniel Vetter Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 11/05/2011 05:10 PM, Daniel Vetter wrote: > 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 > Great. I'll cook up a header file patch with some extra documentation. /Thomas