Hello Emil,
On 05.03.2016 00:19, Emil Velikov wrote:
On 4 March 2016 at 19:02, Michael Thayer <michael.tha...@oracle.com> wrote:
[...]
On 04.03.2016 19:52, Emil Velikov wrote:
[...]
On 4 March 2016 at 14:26, Michael Thayer <michael.tha...@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
_______________________________________________
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
