On Wed, 23 Jun 2021 18:22:47 +0900
Esaki Tomohito <etom@igel.co.jp> wrote:

> 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.

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.


Thanks,
pq