lkml.org 
[lkml]   [2021]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATH 0/4] [RFC] Support virtual DRM
On Tue, 22 Jun 2021 13:02:59 +0900
Esaki Tomohito <etom@igel.co.jp> wrote:

> Hi, Thomas
> Thank you for reply.
>
> On 2021/06/21 16:10, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
> >> Virtual DRM splits the overlay planes of a display controller into
> >> multiple
> >> virtual devices to allow each plane to be accessed by each process.
> >>
> >> This makes it possible to overlay images output from multiple
> >> processes on a
> >> display. For example, one process displays the camera image without
> >> compositor
> >> while another process overlays the UI.
> >
> > I briefly looked over your patches. I didn't understand how this is
> > different to the functionality of a compositor? Shouldn't this be solved
> > in userspace?
>
> I think when latency is important (e.g., AR, VR, for displaying camera
> images in IVI systems), there may be use cases where the compositor
> cannot be used.

Hi,

> Normally, when the image is passed through the compositor, it is
> displayed after 2 VSYNC at most, because the compositor combines the
> image with VSYNC synchronization.

This is not a universal fact. You can write a Wayland compositor that
consistently reaches app-to-screen latency of less than one monitor
refresh cycle, while also using KMS planes.

I believe Weston succeeds in this already if you write the Wayland
application accordingly.


Thanks,
pq
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2021-06-22 09:59    [W:0.378 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site