Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

From: Thomas Hellstrom <thellstrom@vmware.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Daniel Vetter" <daniel.vetter@intel.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack
Date: Wed, 29 Mar 2017 10:04:47 +0200	[thread overview]
Message-ID: <83183012-897b-abdd-2142-e0a68e4b406b@vmware.com> (raw)
In-Reply-To: <20170329080055.e6tbv2i4pm6hbizd@phenom.ffwll.local>

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@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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel