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

Emil Velikov emil.l.velikov at gmail.com
Fri Mar 4 18:52:34 UTC 2016


Hi Michael,

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.
>>   The following patch should fix that.  I say "should" because I had
>> difficulties testing it - the cursor simply disappeared when it should
>> have been rendering in software, though the debugger showed that
>> pixman_image_composite() was getting called whenever the cursor moved,
>> and my kernel driver was getting dirty rectangle information.  My
>> feeling is that the patch is correct and something else is broken.  I
>> have not investigated in depth in case some one else immediately has an
>> idea.
>
>
> My apologies for the noise.  Without going into detail, the failure to show
> the software cursor was due to the unclean way in which we (VirtualBox)
> handle 3D acceleration, and nothing to do with the X server or modesetting.
> I tested my patch again, taking this into account, and it worked as
> expected.
>
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.

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 ?

Regards,
Emil


More information about the xorg-devel mailing list