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.. /Thomas > -Daniel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
