[Intel-gfx] [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

[Thomas Hellstrom]

On 03/29/2017 10:00 AM, Daniel Vetter wrote:
> On Mon, Mar 27, 2017 at 10:31:51AM +0200, Thomas Hellstrom wrote:
>> On 03/27/2017 08:28 AM, Daniel Vetter wrote:
>>> We discussed this quickly on irc, transcribing.
>>>
>>> On Mon, Mar 27, 2017 at 5:01 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>>> Strictly speaking, the (virtual) hardware is too limited to support the
>>>> legacy KMS cursor API. AFAIR e.g. weston at least used to make use of HW
>>>> cursors for other surfaces, not sure that's currently the case though.
>>> That was disabled again because of lack of atomic (together with all
>>> overlay support if your driver isn't atomic). But atomic/universal
>>> planes allows us to at least model vmwgfx correctly. For each crtc
>>> we'd have one primary plane, but only one global cursor plane that we
>>> attach to the cursor slot of each crtc. Then universal/atomic aware
>>> userspace could realize that there's only 1 cursor plane and make sure
>>> it's not over-used.
>> That sounds encouraging. In practice we haven't really seen any problems
>> because most users use vmware tools,
>> which places the outputs in such a way that the cursor location visually
>> coincides for all crtcs.
>> The problem starts if someone would override tools and try to clone the
>> contents across crtcs.
>> The vmware xorg driver has some logic to try to detect such situations
>> and fall back to software cursors, and possibly we might have to, at
>> some point, implement software cursor composition in the kernel, but for
>> now we live with the potential possibilty that users will see the cursor
>> jumping across the screens..
> Ok, I've pulled in the series, except this patch plus the few cleanups
> that depend upon it. I'll respin this as soon as vmwgfx atomic has landed,
> with either a local mutex (if you still have more sw cursor planes than
> real ones) or no changes (if your universal cursor code is fixed to only
> have one cursor for the entire device instance).
>
> Thanks, Daniel

Thanks,

In the patch series we have added a local spinlock (cursor_lock) to
protect from
concurrent register access.

/Thomas