Re: KMS cursor BO semantics

[Thomas Hellstrom <thellstrom@vmware.com>]

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 <ihadzic@research.bell-labs.com>
> 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