Modesetting can't switch back from a software to a hardware cursor (patch to follow)

[Michael Thayer]

Hello Emil,

On 05.03.2016 00:19, Emil Velikov wrote:
> On 4 March 2016 at 19:02, Michael Thayer <michael.thayer at oracle.com> wrote:
[...]
>> On 04.03.2016 19:52, Emil Velikov wrote:
[...]
>>> On 4 March 2016 at 14:26, Michael Thayer <michael.thayer at oracle.com>
>>> wrote:
>>>> On 02.03.2016 18:43, Michael Thayer wrote:
>>>>> At present if modesetting ever fails to set a hardware cursor it
>>>>> switches back to a software one and stays that way until it is unloaded.
[...]
>>> Note that I'm not the person who wrote any of that code, although I do
>>> wonder... Why do we have to attempt/probe for hardware cursor
>>> everything time ? If the first invocation has failed it is reasonable
>>> to expect that all/most sequential ones will also fail.
>>
>> Thanks for taking a look.  In VirtualBox and possibly other virtualisation
>> environments, the user may enable or disable mouse integration with the host
>> system.  Handling this involves enabling (for integration) and disabling
>> (for no integration) hardware cursor support.  So rendering a cursor in
>> hardware can fail on one invocation and succeed for the same cursor on the
>> next.
>>
> Interesting. Have not seen such a option to toggle it as the VM was
> running, although it's been a couple of years since I used one.
> Do other drivers do the same thing to attach/detach the cursor ? I'd
> imagine so although it'll be worth a check.

Actually I forgot the more important use case - many drivers for 
physical hardware can display some but not all cursors in hardware (Ajax 
told me once that the details of which can be and which not can be 
rather non-obvious).  So forbidding all hardware cursor usage as soon as 
one fails is not optimal.

>
> Personally I would add that in the commit message, to make it
> abundantly obvious.

Noted.

>>> Is the failed call to drmModeSetCursor/drmModeSetCursor2 an
>>> intentional behaviour, it suspiciously sound like a bug in the drm
>>> module (some along the line) to me. Which DRM module is that ?
>>
>> Do you mean the -EINVAL?  That is used to mean that drmModeSetCursor2 is not
>> supported, but can also mean that a particular cursor cannot be rendered in
>> hardware.  I suppose you could call that a bug if that is what you were
>> referring to.
>>
> -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.

> All in all please consider my questions/suggestions as general
> curiousness, as opposed to something being wrong with the patch.
>
> Thanks
> Emil

Thanks,

Michael

> P.S. Just realised we met at FOSDEM. Howdy Michael :-)

Howdy!
-- 
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