Switching between a software and a hardware mouse cursor

Michael Thayer michael.thayer at oracle.com
Tue Mar 18 03:17:49 PDT 2014


On 05/03/14 19:45, Adam Jackson wrote:
> On Thu, 2014-02-27 at 15:46 +0100, Michael Thayer wrote:
>
>> Another would be
>> to add a return value to the DDX CRTC functions "load_cursor_argb", so
>> that if the KMS driver failed to set the cursor, "modesetting" could
>> pass this on to the X server.
>
> Actually we really should make load_cursor_argb return something other
> than void.  Some particularly incapable server GPUs have format
> restrictions on their hardware cursors that mean _some_ ARGB cursors
> could be made to work but not all; and right now, the fallback code in
> -modesetting doesn't get this case right, and you end up with no cursor
> at all.

I have been looking at what this would take, and what rather puts me off 
is that it would mean patching all supported video drivers without even 
the means to test them (the patches will be mostly be adding "return 
TRUE" in the right place of course, but you know how it is; how is this 
sort of thing normally handled?)

Thinking a bit more, what would be ideal for me would be a way of 
telling the X server to use or not to use the hardware cursor of a 
particular card.  A RandR request might fit the picture here.  Is this 
something which might be acceptable?

Even nicer would be a way in addition of telling the server that a 
particular hardware cursor is linked to a particular input device, and 
that it should use a software cursor if it wants the cursor to be 
somewhere other than the position reported by the device; I can't 
immediately think though where that would fit in cleanly, and neither 
can I immediately think of any other potential users of such an interface.

Of course, from my point of view, unlike using the "load_cursor_argb" 
API which just would just pass through to the KMS driver, these two 
would both be X.Org-only solutions to my problem which won't help 
whenever we want to start supporting Wayland.

Regards,

Michael
-- 
ORACLE Deutschland B.V. & Co. KG   Michael Thayer
Werkstrasse 24                     VirtualBox engineering
71384 Weinstadt, Germany           mailto:michael.thayer at oracle.com

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


More information about the xorg-devel mailing list