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

[Simon Ser]

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.