On 05.03.2016 09:42, Michael Thayer wrote:
[...]
On 05.03.2016 00:19, Emil Velikov wrote:
-EINVAL is interpreted by most/all of us as not supported (too old of
a kernel). Although another thing was at the back of my mind - why are
you removing the use_set_cursor2 static boolean. In all fairness, I
doubt that we can get the actual integration happening between the two
SetCursor* calls. So one might want to keep it...
I dare say we could restore this if we fixed all kernel drivers (that
care) never to return -EINVAL in their SetCursor2 call-back. Any
thoughts what else they should return to say that a given cursor is
(possibly temporarily) not supported by the hardware? On the other
hand, currently only qxl and virtgpu should care. virtgpu returns
-EINVAL if the cursor passed in by user space is invalid, and qxl could
possibly pass up a -EINVAL from an API that it calls.
Actually SetCursor2 is supported by all kernels since 3.11, released in
September 2013. So if anything it would make sense these days not to
try the fall-back at all. That said, I wouldn't mind if this patch
could be applied to older server branches too, since we want to support
older distributions (one of our important use cases), and that increases
the chances.
Regarding integration between the two APIs (I didn't answer that
properly), on the whole we have the following cases: SetCursor2 is
supported and the cursor is supported. In that case the first call to
SetCursor2 will succeed and we will never fall back. SetCursor2 is
supported and the cursor is not supported but the driver returns -EINVAL
to say so. In that case we will try SetCursor which will fail too, no
big issue it seems to me. SetCursor2 is supported and the driver
returns something else. Then we will not try the fall-back. SetCursor2
is not supported. Then we will always try both APIs but only use
SetCursor. Not optimal, but I think that keeping the code simple is
more important. Generally, we will always use either SetCursor2 or
SetCursor, in practice we will never mix and match, so I don't think the
integration is a problems.
Regards,
Michael
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
