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@xxxxxxxxxxxxx:
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)
