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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux