Re: [PATCH v2] drm: support hotspot for universal plane cursors

[Michel DÃnzer]

On 18.11.2015 17:51, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel DÃnzer wrote:
>> On 18.11.2015 01:29, Daniel Vetter wrote:
>>>
>>> And no, I have absolutely no idea why radeon is pulling some tricks here,
>>> which have been added in
>>>
>>> commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
>>> Author: Michel DÃnzer <michel.daenzer@xxxxxxx>
>>> Date:   Tue Nov 18 18:00:08 2014 +0900
>>>
>>>     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
>>>
>>> Michel/Alex, can you please shed some light onto this?
>>
>> As described in the rest of the commit log, the intention was to avoid
>> the cursor intermittently appearing in the wrong location with existing
>> userspace which sets the cursor BO in one ioctl call and the new
>> position in another ioctl call.
>>
>>
>>> radeon is the only driver doing this, making this interface inconsistent.
>>
>> It's only inconsistent in the case that userspace updates the cursor
>> position to account for the new hotspot position in one ioctl call
>> first, and only then sets the new BO in another ioctl call. In all other
>> cases, the cursor position passed in by userspace is preserved.
>>
>> Anyway, in the meantime it has become apparent that this change didn't
>> fully fix the problem, so feel free to revert it.
> 
> Yeah I read the commit message but didn't understand what it's doing.
> After some discussion with Alex on irc I realized that the fixup is only
> applied in when updating the cursor bo and changing the hotspot to avoid
> that kind of flickering. That problem is solved though on the kernel side
> with universal planes (where we don't artificially split up the cursor
> update into a move + bo-update for the driver interface any more). And
> it's fixable in userspace even with legacy cursor interfaces since the
> ioctl allows you to move + update at the same time too. It's just that X
> doesn't provide that interface to the driver in a useful way.

Well, the legacy cursor interfaces currently don't allow the driver to
prevent the hardware from updating the cursor between the cursor_set /
cursor_move calls. Anyway, I tried adding a cursor_lock hook for that
purpose and adapting userspace accordingly, but it still doesn't seem to
fully fix the problem. So I'm leaving it to somebody else / another day. :)


-- 
Earthling Michel DÃnzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/