drm/udl: Implementation of atomic cursor drm_plane

[Lukasz Spintzyk]

On 7/2/2024 2:02 PM, Lukasz Spintzyk wrote:
> On 6/24/2024 12:05 PM, Daniel Vetter wrote:
>> CAUTION: Email originated externally, do not click links or open 
>> attachments unless you recognize the sender and know the content is safe.
>>
>>
>> On Mon, Jun 24, 2024 at 09:28:29AM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 24.06.24 um 09:10 schrieb lukasz.spintzyk at synaptics.com:
>>>> This brings cursor on DisplayLink USB2.0 device on ChromeOS 
>>>> compositor that requires either crtc'c cursor_set callback
>>>> or cursor drm_plane. Patch was tested on ChromeOS and Ubuntu 22.04 
>>>> with Gnome/Wayland
>>>
>>> NAK on this patchset. UDL has no HW cursor support, so we won't 
>>> implement
>>> this in the driver. Software blending should be done in userspace, 
>>> where you
>>> have CPU SIMD available.

Thank you Thomas,

Please check, my answer below Daniel's response.
I think that compositor still benefits cursor blending in the driver.
At least for ChromeOS in which udl based devices are only one without 
cursor plane support. I believe it can simplify compositor code in this 
case.

Another topic,
What do you think about "[PATCH 4/4] drm/udl: Shutdown all CRTCs on usb 
disconnect", IMO it is unrelated and happened to appear more frequently 
with cursor plane.

Shall I re-upload it as separate patchset?

regards
Łukasz Spintzyk

>>
>> I think for drivers which do cpu upload and are vblank driven there's
>> maybe a case for kernel implemented cursors due to latency reduction if
>> the blending happens as late as possible. But udl just goes right ahead
>> and uploads, so this doesn't help I think. damage tracking should, but we
>> already have that.
> 
> Sorry, I don't get what you mean here. This implementation uploads only 
> damaged primary plane area (gathered in 
> udl_cursor_plane_helper_atomic_update) and uploads it to device in 
> following immediately udl_primary_plane_helper_atomic_update. No full 
> primary plane update is done in this case (which is done only when 
> plane_state->fb != old_plane_state->fb, please check updated 
> udl_primary_plane_helper_atomic_update)
> 
> Sorry i don't have hard numbers for that but this in overall should 
> improve cursor latency (especially for move events) in which case whole 
> primary plane render is saved and cursor update can be done without 
> waiting for next vsync of the primary plane.
> 
> Ihmo this implementation can be useful to test and implement atomic 
> updates for cursor plane in compositors.
> 
> Anyway thanks for your(Daniel and Thomas) responses, if there is 
> something I can do to push it then let me know.
> 
> regards
> Łukasz Spintzyk
>>
>> So concurring here.
>> -Sima
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.ffwll.ch&d=DwIBAg&c=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY&r=0p1mI1lUPD-etxZm5xwnMe2dJnw8yCkW8EVTCGmBDPo&m=M1yfa7XuJVH9rCMPSuFfUD51RJsC3N6CNXSv9yDKmfmSUijg5Z3ngLzUqKBnbTgJ&s=Cs7RKpEwGAz4cdSnl3jqFctOKhaOpoHPGw3tSRPW2OI&e=
>