On 2021/06/23 17:39, Pekka Paalanen wrote: > On Wed, 23 Jun 2021 15:56:05 +0900 > Esaki Tomohito <etom@xxxxxxxxxx> 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@xxxxxxxxxx> 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
