On Tue, 31 Jan 2023 11:21:18 +0000 Simon Ser <contact@xxxxxxxxxxx> wrote: > On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > 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? > > 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
Attachment:
pgpKoACg_fh6i.pgp
Description: OpenPGP digital signature
