Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 23 Jun 2021 16:39:28 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Esaki Tomohito <etom@igel.co.jp>
Cc:     Thomas Zimmermann <tzimmermann@suse.de>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
        dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        linux-doc@vger.kernel.org,
        Damian Hobson-Garcia <dhobsong@igel.co.jp>,
        Takanari Hayama <taki@igel.co.jp>
Subject: Re: [PATH 0/4] [RFC] Support virtual DRM
Message-ID: <20210623143928.ickbxz32w6lbpofn@gilmour>
References: <20210621062742.26073-1-etom@igel.co.jp>
 <9853d0a9-6053-db64-9c79-40b7e0689eec@suse.de>
 <20210621092454.jvdmelk2h427jn5v@gilmour>
 <cc08f858-7440-05f9-0d10-243f5115d209@igel.co.jp>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="zrpqm6ro3pys2ppq"
Content-Disposition: inline
In-Reply-To: <cc08f858-7440-05f9-0d10-243f5115d209@igel.co.jp>
Precedence: bulk


--zrpqm6ro3pys2ppq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 22, 2021 at 01:36:48PM +0900, Esaki Tomohito wrote:
> Hi, Maxime
> Thank you for reply.
>=20
> On 2021/06/21 18:24, Maxime Ripard wrote:
> > Hi,
> >=20
> > 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 mu=
ltiple
> >>> virtual devices to allow each plane to be accessed by each process.
> >>>
> >>> This makes it possible to overlay images output from multiple process=
es on a
> >>> display. For example, one process displays the camera image without c=
ompositor
> >>> 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 solv=
ed in
> >> userspace?
> >=20
> > I think there could be a bunch of use-cases for something that could
> > "steal" a plane without the compositor knowing.
> >=20
> > 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.
> >=20
> > 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) ?
> >=20
>=20
> I will reconsider the DT bindings.
>=20
> We want to separate the resources from the master in units of planes,
> so we proposed virtual DRM.
> By separating the plane from the master and making it appear as
> a virtual DRM devicein userland, the plane can be accessed from
> userland using the general DRM API.
> What do you think about this idea?

I guess you'd need to detail a bit more what your use case is exactly,
and what issue you're trying to address.

Generally speaking, I'm not really sure how you can separate a KMS
driver from its planes.

Like, assuming that you have that super important application putting
the rear-end camera on the display: I'd assume you want the connector
and bridges to remain enabled? How are you going to synchronize with the
compositor if it wants to disable it, or change resolution?

Similarly, some features exposed on the connector, like bpc, might
affect the input format you want to have for your planes?

Maxime

--zrpqm6ro3pys2ppq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYNNHoAAKCRDj7w1vZxhR
xSYqAQCeBYrlpqR5FSj6MJ47x6cTdMpmzNwtz5kdH40wQJkV7AD/de9z5dNUHVoD
IFn98/cS3zYxIr7sbZYk5LkBlbuvaAg=
=owdM
-----END PGP SIGNATURE-----

--zrpqm6ro3pys2ppq--