[RFC PATCH v3 0/3] Support for Solid Fill Planes

[Pekka Paalanen]

On Tue, 31 Jan 2023 11:21:18 +0000
Simon Ser <contact at emersion.fr> wrote:

> On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Tue, 31 Jan 2023 10:06:39 +0000
> > Simon Ser <contact at emersion.fr> wrote:
> >   
> > > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > >   
> > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that
> > > > approach rejected?    
> > > 
> > > Ideally we don't want to allocate any GPU memory for the solid-fill
> > > stuff. And if we special-case 1x1 FB creation to not be backed by real
> > > GPU memory then we hit several situations where user-space expects a
> > > real FB but there isn't: for instance, GETFB2 converts from FB object
> > > ID to GEM handles. Even if we make GETFB2 fail and accept that this
> > > breaks user-space, then there is no way for user-space to recover the
> > > FB color for flicker-free transitions and such.
> > > 
> > > This is all purely from a uAPI PoV, completely ignoring the potential
> > > issues with the internal kernel abstractions which might not be suitable
> > > for this either.  
> > 
> > I mean a real 1x1 buffer: a dumb buffer.
> > 
> > It would be absolutely compatible with anything existing, because it is
> > a real FB. As a dumb buffer it would be trivial to write into and read
> > out. As 1x1 it would be tiny (one page?). Even if something needs to
> > raw-access uncached memory over 33 MHz PCI bus or whatever the worst
> > case is, it's just one pixel, so it's fast enough, right? And it only
> > needs to be read once when set, like USB display drivers do. The driver
> > does not need to manually apply any color operations, because none are
> > supported in this special case.
> > 
> > One can put all these limitations and even pixel format in the plane
> > property that tells userspace that a 1x1 FB works here.
> > 
> > To recap, the other alternatives under discussion I see right now are:
> > 
> > - this proposal of dedicated fill color property
> > - stuffing something new into FB_ID property
> > 
> > There is also the question of other kinds of plane content sources like
> > live camera feeds where userspace won't be shovelling each frame
> > individually like we do now.
> > 
> > 1x1 dumb buffer is not as small and lean as a dedicated fill color
> > property, but the UAPI design questions seem to be much less. What's
> > the best trade-off and for whom?  
> 
> By "real memory" yes I mean the 1 page.
> 
> Using a real buffer also brings back other discussions, e.g. the one about
> which pixel formats to accept.

Yeah, which is why I wrote: "One can put all these limitations and even
pixel format in the plane property". It doesn't even need to be a
variable in the UAPI, it can be hardcoded in the UAPI doc.

Please, do not understand this as me strongly advocating for the real FB
approach! I just don't want that option to be misunderstood.

I don't really care which design is chosen, but I do care about
documenting why other designs were rejected. If the rejection reasons
were false, they should be revised, even if the decision does not
change.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20230131/47a4d3ab/attachment.sig>