KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 4, 2011 at 11:59 PM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> 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
>
>
>
>

I see your point, i certainly prefer the "doesn't need tricks"
approach. Maybe allow for some kind of hybrid approach, require the
ioctl for every cursor change, but allow drivers to do a kind of lazy
implementation that simply attaches the buffer to the hardware and let
it handle it. If they want to avoid copying overhead or stuff like
that. This would impose some restrictions on what you can do with a
cursor buffer after calling the ioctl, specifically you would be
required to leave the content alone, except for cursor updates.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.