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

[Alexandre Courbot]

On Wed, Sep 28, 2016 at 12:05 PM, Michel Dänzer <michel at daenzer.net> 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.

Correct. Tegra cannot manage the cursor format that modesetting is
trying to use, so the MODE_SETTING ioctl fails and we fall back to
software cursor.