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

Thomas Hellstrom thellstrom at vmware.com
Mon Mar 27 08:31:51 UTC 2017


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

/Thomas



> -Daniel





More information about the dri-devel mailing list