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:   Mon, 21 Jun 2021 11:24:54 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Thomas Zimmermann <tzimmermann@...e.de>
Cc:     Tomohito Esaki <etom@...l.co.jp>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        dri-devlel@...ts.freedesktop.org,
        linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATH 0/4] [RFC] Support virtual DRM

Hi,

On Mon, Jun 21, 2021 at 09:10:19AM +0200, Thomas Zimmermann wrote:
> 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 there could be a bunch of use-cases for something that could
"steal" a plane without the compositor knowing.

Something I'd really like to work at some point for example is that the
downstream RaspberryPi display driver has a visual clue when it's
running too hot or is in over-current.

I don't think this is the right solution though. The DT binding makes it
far too static, and if there's a compositor I'd assume it would want to
know about it somehow (at least if it's from the userspace) ?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)