[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7cde82a9-c60c-e527-eeac-eaad0c5842a1@metux.net>
Date: Mon, 21 Jun 2021 18:05:08 +0200
From: "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To: Tomohito Esaki <etom@...l.co.jp>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
Cc: 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
On 21.06.21 08:27, Tomohito Esaki wrote:
Hi,
> 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.
Are you attempting to create an simple in-kernel compositor ?
I don't think that's not the way to go, at least not by touching each
single display driver, and not hardcoding the planes in DT.
What's the actual use case you're doing that for ? Why not using some
userland compositor ?
If you really wanna build a kernel compositor, it should be completely
independent of hw drivers. (well, almost - in case of gpus shall be
used, the commands obviously need to be dispatched the actual driver)
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287
Powered by blists - more mailing lists