On 3/20/20 12:47 PM, Thomas Hellström (VMware) wrote:
On 3/20/20 12:27 PM, Simon Ser wrote:
On Friday, March 20, 2020 11:59 AM, Thomas Hellström
<thomas_os@xxxxxxxxxxxx> wrote:
On 3/20/20 10:13 AM, Pekka Paalanen wrote:
It seems people are also forgetting the problem of associating the
cursor plane with an input device, so that whatever is looking to
mangle the cursor plane behind the KMS app's back would know how
to do
it right.
My first thought for that is a new cursor plane property with the
value
of major, minor of the kernel input device that userspace is using to
control the cursor plane. This property should be set by userspace
only
when there is exactly one kernel input device it uses for controlling
the cursor plane. Setting this property to none/disabled would be a
clear indication that "seamless mode" would be unwanted. The DRM
driver or whatever it talks to could then check if the cursor
plane is
indeed controlled by the input it so far has only assumed and
automatically choose correctly between seamless mode or not.
Are you sure this i really needed? VMware's SVGA device checks whether
the guest cursor position and host cursor position are reasonably
aligned, and if not, composites the guest cursor over the display
plane.
So if you, for example, attach a passthrough USB mouse to the VM
while
running in seamless mode, things "just work". Similarly if you were to
attach a kms-based vnc solution that behaved in the same way and that
created a new input device, things would also look fine, except for
temporary cursor jumps when you switch input device.
Seems more like a workaround than a real solution.
That may be the case, but still it works and if you have multiple
clients it always allows the active client run in seamless mode.
Besides, if people think supporting KMS hotspots is already hard
enough, the chance of having them supplying the correct input device
is small.
/Thomas
To be clear about this, I'm not *against* a property associating a
device with a cursor plane as long as it's just a hint. However in the
VMware case, it's unlikely that we will try to implement any kernel
driver support for it since we have a working solution and it also may
not be possible. (Some remoting solutions only work when seamless mode
is enabled).
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
