KMS cursor BO semantics

[Thomas Hellstrom]

On 11/04/2011 11:49 PM, Maarten Maathuis wrote:
> On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom<thellstrom at vmware.com>  wrote:
>    
>> 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
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>      
> As far as i know nouveau keeps an internal buffer object for the
> cursor and relies purely on the ioctl to copy the cursor into the
> actual cursor memory area. So why do you need tricks?
>
>    
Because I have a hard time judging whether the Intel implementation 
(needs tricks) or the Nouveau implementation (doesn't need tricks) 
should define the semantics of the ioctl, although I would prefer we 
could all agree on the "doesn't need tricks" semantics and put that down 
in writing in the drm_mode.h header file.

/Thomas