linux-kernel - Re: [PATH 0/4] [RFC] Support virtual DRM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Jun 2021 11:12:16 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Esaki Tomohito <etom@...l.co.jp>
Cc:     devicetree@...r.kernel.org, Takanari Hayama <taki@...l.co.jp>,
        linux-doc@...r.kernel.org, David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Damian Hobson-Garcia <dhobsong@...l.co.jp>
Subject: Re: [PATH 0/4] [RFC] Support virtual DRM

Hi

Am 22.06.21 um 06:02 schrieb Esaki Tomohito:
> 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.
> 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. On the other hand, if we use vDRM, the
> image will be displayed at the next VSYNC, so it will be displayed after
> 1 VSYNC at most.

Other commenters already addressed these points.

> 
> Also, since the compositor is a single point of failure, we may not want
> to make it dependent on it.

The kernel is also a single point of failure.

TBH I don't think this feature should be merged until there's a clear 
use case that cannot be solved in userspace idiomatically.

Best regards
Thomas

> 
> Best regards
> Tomohito Esaki
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)