drm/udl: Implementation of atomic cursor drm_plane

[Thomas Zimmermann]

Hi

Am 02.07.24 um 14:07 schrieb 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.

But it complicates kernel code, which is a bad tradeoff.

Wrt the damage handling discussion in the other email, there's 
damage-handling support in the udl driver. It will only upload the small 
region around the cursor if the userspace tells it to. IIRC userspace 
needs to invoke the DIRTYFB [1] ioctl after updating the framebuffer data.

[1] 
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L634

>
> 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.

The patch's description mentions kernel panics. AFAICT the cursor-plane 
patches don't use drm_dev_enter() and _exit(). That would explain the 
panics. Do they also happen without the cursor-plane code?

Best regards
Thomas

>
> 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= 
>>>
>>
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)