From: Esaki Tomohito <etom@igel.co.jp>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
devicetree@vger.kernel.org, Takanari Hayama <taki@igel.co.jp>,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-doc@vger.kernel.org, David Airlie <airlied@linux.ie>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Damian Hobson-Garcia <dhobsong@igel.co.jp>
Subject: Re: [PATH 0/4] [RFC] Support virtual DRM
Date: Wed, 23 Jun 2021 18:22:47 +0900 [thread overview]
Message-ID: <ab816c34-ff98-911f-e53d-b91cd3be6f2b@igel.co.jp> (raw)
In-Reply-To: <20210623113922.1e603139@eldfell>
On 2021/06/23 17:39, Pekka Paalanen wrote:
> On Wed, 23 Jun 2021 15:56:05 +0900
> Esaki Tomohito <etom@igel.co.jp> wrote:
>
>> Hi,
>> Thank you all for your comments.
>>
>> On 2021/06/22 17:12, Pekka Paalanen wrote:
>>> On Tue, 22 Jun 2021 13:03:39 +0900
>>> Esaki Tomohito <etom@igel.co.jp> wrote:
>>>
>>>> Hi, Enrico Weigelt
>>>> Thank you for reply.
>>>>
>>>> On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote:
>>>>> 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 think the basic idea is the same as DRMlease.
>>>
>>> Hi,
>>>
>>> indeed. Why not use DRM leases instead?
>>>
>>
>> In this use case, I understand that this is not possible with DRM lease,
>> am I wrong?
>> I understand that it’s not possible to lease a plane and update planes
>> on the same output independently from different processes in current DRM
>> lease.
>>
>> If this is correct, what do you think of adding support for plane leases
>> to the DRM lease to handle this case?
>
> Hi,
>
> I would love to see support added for leasing individual planes,
> especially to replace the virtual DRM proposal which seems to be
> eradicating everything that atomic modesetting and nuclear pageflip
> have built over the many years.
>
> However, please note that "on the same output independently" is
> physically impossible. Semantically, the planes define what a CRTC
> scans out, and the CRTC defines the scanout timings. Therefore it is not
> possible to update individual planes independently, they will all
> always share the timings of the CRTC.
>
> That combined with KMS not allowing multiple updates to be queued at
> the same time for the same CRTC (atomic commits and legacy pageflips
> returning EBUSY) makes the plane updates very much inter-dependent.
>
> If you want to avoid EBUSY and have planes update on the vblank you
> intended, you really need a userspace compositor to pull everything
> together *before* submitting anything to the kernel.
Hi,
Thank you for your comments and advice.
I will consider leasing a plane.
Thanks,
Esaki
next prev parent reply other threads:[~2021-06-23 9:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-21 6:27 [PATH 0/4] [RFC] Support virtual DRM Tomohito Esaki
2021-06-21 6:27 ` [PATH 1/4] drm: Add Virtual DRM device driver Tomohito Esaki
2021-06-21 6:27 ` [PATH 2/4] rcar-du: Add support virtual DRM device Tomohito Esaki
2021-06-21 6:27 ` [PATH 3/4] dt-bindings: display: Add virtual DRM Tomohito Esaki
2021-06-21 6:27 ` [PATH 4/4] doc-rst: Add virtual DRM documentation Tomohito Esaki
2021-06-21 7:10 ` [PATH 0/4] [RFC] Support virtual DRM Thomas Zimmermann
2021-06-21 9:24 ` Maxime Ripard
2021-06-22 4:36 ` Esaki Tomohito
2021-06-23 14:39 ` Maxime Ripard
2021-06-22 4:02 ` Esaki Tomohito
2021-06-22 7:57 ` Pekka Paalanen
2021-06-23 8:04 ` Michel Dänzer
2021-06-23 8:21 ` Esaki Tomohito
2021-06-22 9:12 ` Thomas Zimmermann
2021-06-21 16:05 ` Enrico Weigelt, metux IT consult
2021-06-22 4:03 ` Esaki Tomohito
2021-06-22 8:12 ` Pekka Paalanen
2021-06-22 19:12 ` Daniel Vetter
2021-06-23 6:56 ` Esaki Tomohito
2021-06-23 8:39 ` Pekka Paalanen
2021-06-23 9:22 ` Esaki Tomohito [this message]
2021-06-23 11:41 ` Pekka Paalanen
2021-06-25 1:55 ` Esaki Tomohito
2021-06-21 6:43 Tomohito Esaki
2021-06-22 8:04 ` Simon Ser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ab816c34-ff98-911f-e53d-b91cd3be6f2b@igel.co.jp \
--to=etom@igel.co.jp \
--cc=airlied@linux.ie \
--cc=devicetree@vger.kernel.org \
--cc=dhobsong@igel.co.jp \
--cc=dri-devel@lists.freedesktop.org \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=lkml@metux.net \
--cc=ppaalanen@gmail.com \
--cc=taki@igel.co.jp \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).