KMS cursor BO semantics

[Thomas Hellstrom]

On 11/04/2011 04:34 PM, Daniel Vetter wrote:
> On Fri, Nov 04, 2011 at 12:59:59PM +0100, 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?
>>      
> On i915 we need the cursor in physical memory for some (old) platforms,
> which is seperate storage from the bo backing storage. So we have the same
> problem. We've solved it by intercepting pwrite ioctl calls and demanding
> that userspace only uses these for cursor updates. Is there a special
> reason you can't use such a driver-specific trick?
> -Daniel
>    
We have something similar in use today: We snoop DMAs to hardware
cursor surfaces, but this gets a bit nasty when apps start to do 
hardware render to cursor surfaces, and
we simply ignore that today.

Furthermore,  maps rather than pwrites are the common usage-pattern for 
buffer-backed cursors on vmwgfx, and while it's possible to dirty those 
buffers based on page-faults, like we do with fb surfaces, we'd rather 
avoid having to implement and maintain that.

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?

/Thomas