On Tue, 31 Jan 2023 10:06:39 +0000 Simon Ser <contact@xxxxxxxxxxx> wrote: > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen <ppaalanen@xxxxxxxxx> 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? Thanks, pq
Attachment:
pgpdatE7vztE_.pgp
Description: OpenPGP digital signature
