[PATCH xserver] modesetting: always set a hardware cursor when requested to load one.

[Hans de Goede]

Hi,

On 28-09-16 05:05, Michel Dänzer wrote:
> On 27/09/16 10:54 PM, Michael Thayer wrote:
>> On 27.09.2016 12:06, Hans de Goede wrote:
>>> On 23-09-16 10:20, Hans de Goede wrote:
>>>> On 09/16/2016 06:52 PM, Michael Thayer wrote:
>>>>> When the X server asks us to load a hardware cursor, that
>>>>> request is always followed up by a request to show it if we
>>>>> report success, or to hide it if we report failure.  Therefore
>>>>> it makes no sense to suppress the request if the cursor is not
>>>>> currently visible.
>>>>
>>>> Ok, I've just spend the last half hour tracing (using grep) all
>>>> callers of load_cursor_argb_check and you're right, either the
>>>> cursor is already visible (XRecolorCursor does this), or it will
>>>> get shown directly after the drmmode_load_cursor_argb_check()
>>>> call.
>>>
>>> And despite double checking I still missed a trouble-some scenario
>>> here.
>>>
>>> If we've 2 monitors active, then as the cursor moves from one to
>>> the other show()/hide() gets called on them.
>>>
>>> If the cursor then changes load_cursor_argb_check() gets called on
>>> all active crtc-s causing the cursor to now be shown on both
>>> monitors at the same time, not good.
>>
>> Indeed.  Looking at other ways of handling this, but the whole thing
>> is somewhat tricky due to the differences in how the X server and
>> the kernel handle cursor setting.  I think that the most correct way
>> to fix this would be to allow show and hide cursor operations to
>> return failure too, but that would be a very invasive change.  A less
>> invasive but also less clean change would be to extend the first time
>> hack to also trigger if a load happens when the cursor is hidden
>> globally (or perhaps better, if it is hidden on all crtc-s at the
>> time of the load).  For VirtualBox, if a cursor load succeeds on one
>> crtc we know it will succeed on any, but I wonder whether that would
>> apply to other users.  I also wonder which other potential users
>> there are.  So far most other people use their own DDX instead of
>> modesetting.  Alexandre, did you say this was an issue for Tegra?
>
> IIRC the issue with Tegra is that it can't use the HW cursor at all for
> some reason, not that it sometimes can and sometimes can't.
>
>
>> And it is potentially interesting for Qemu for the same reasons that
>> it is for us (relative input device support).
>
> TBH, I feel like the issues you're having with VirtualBox would be
> better dealt with at the virtual GPU hardware level, by making the HW
> cursor work reliably for guests and making it the hypervisor's
> responsibility to draw the cursor on the host side when the HW cursor
> can't be used there.

Yes that would be me suggestion too, I think that playing the whole
now we support hw cursor now we don't game does not really work. Esp.
since if the guest is just idle, it will not try any drmSetCursor
calls, so it will not even know the support has changed underneath it.

Regards,

Hans