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