On 2021/06/23 20:41, Pekka Paalanen wrote: > On Wed, 23 Jun 2021 18:22:47 +0900 > Esaki Tomohito <etom@xxxxxxxxxx> wrote: > >> 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. > > Hi, > > I wish you considered a userspace compositor first, once more, with > passion. > > It does not need to be Weston, and it does not need to use Wayland. > Just a userspace daemon that owns the whole display device and somehow > talks to whatever else wants stuff on screen. > > I have not seen any evidence that leasing individual planes would do > you any good. I can easily see it doing you harm. I'm only saying that > it would be better than the virtual DRM proposal if you absolutely have > to go there. Please, consider not going there at all. > > "On the same output independently" is not possible for the very simple > reason that the pixel data needs to be streamed serially to a monitor. > Hi, Thank you for your advice. Once again, I'll consider a userspace compositor first. Best regards Esaki
