From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: KMS cursor BO semantics Date: Fri, 04 Nov 2011 15:38:59 +0100 Message-ID: <4EB3F903.40604@vmware.com> References: <4EB3D3BF.70909@vmware.com> 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 879729F30E for ; Fri, 4 Nov 2011 07:41:29 -0700 (PDT) In-Reply-To: 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: Ilija Hadzic Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 11/04/2011 03:36 PM, Ilija Hadzic wrote: > > > On Fri, 4 Nov 2011, Thomas Hellstrom wrote: > >> Hi. >> >> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR >> iotcl: >> >> Some hardware (vmware's virtual in particular) may not be able to >> pick up the changes from a bo directly, since the cursor data is sent >> though the command stream. Hence we need a notification when the >> cursor image has changed. >> >> Could we *require* that a cursor image change needs to be followed by >> an ioctl call with the flag >> DRM_MODE_CURSOR_BO? >> >> Thanks, >> Thomas >> > > FWIW, Acked-by: Ilija Hadzic > I have a few places where I could use such an ioctl. > Well, the idea was to reuse the DRM_IOCTL_MODE_CURSOR ictl that sets the cursor BO, and require that it is re-emitted once the cursor image has changed, since I guess that's what many X servers do anyway. > BTW, Thomas, in the above "since the cursor data is sent though the > command stream", did you mean "since the cursor data is *not* sent > though the command stream". If it was sent, through command stream, > then CS ioctl would know when the cursor changes. I meant the device interface, not the drm interface. So when we have a new cursor image, we need to collect the scanline data an send it through the device command stream. We don't export that possibility in the DRM interface. > > My understanding is that the cursor data are mmap-ed letting userland > poke it at will (so the case when an "hourglass" changes into "arrow" > is particularly hard to know that it happened). Yes. Hardware that scan out directly from the cursor BO don't really need to know, but we do. > > -- Ilija Thanks, /Thomas