Hello Dave,
On 04/04/14 01:21, Dave Airlie wrote:
load_cursor_argb() may need to be able to fail and have the server
fall back to a software cursor in at least the following
circumstances. 1) The hardware can only support some ARGB cursors
and this does not just depend on cursor size. 2) Virtual hardware
may not wish to pass through a cursor to the host at a particular
time but may wish to accept the same cursor at another time. This
patch adds a return value to the API and makes the server do the
software fall-back on failure.
Signed-off-by: Michael Thayer <[email protected]>
I think this is a welcome ABI break, and I probably should have done
something like it ages ago when doing -modesetting,
Reviewed-by: Dave Airlie <[email protected]>
Thanks for the review! Does X.Org custom say that I should sent patches
(which I obviously can't test) for all or some of the public drivers, or
that the driver maintainers should do that? And my question about
whether a similar patch for set_cursor_position() would make sense is
still open (I assume this is relevant for Qemu too):
VirtualBox can use the host cursor as a hardware cursor for a guest
system, but it can't change its position, so if the guest wants the
cursor anywhere except where the host put it (e.g. another device
controlling it, or the cursor confined to a screen region) it needs
to draw it itself. Of course, set_cursor_position() should still
be called even after it has failed once so that we could switch
back if the positions matched again.
Regards,
Michael
--
ORACLE Deutschland B.V. & Co. KG Michael Thayer
Werkstrasse 24 VirtualBox engineering
71384 Weinstadt, Germany mailto:[email protected]
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
