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