Hi, On 28 July 2017 at 01:11, Keith Packard <kei...@keithp.com> wrote: > Eric Anholt <e...@anholt.net> writes: >> I think one option would be to have this extension create pixmaps with a >> depth equal to the highest populated bit of the fourcc plus one. Sure, >> it's weird that rgbx8888 and xrgb888 have a different depth, but "depth" >> is a pretty awful concept at this point. > > It's just supposed to express which bits in the pixel contribute to > generating the resulting color; bits outside of depth 'don't matter', > and may not even be retained. Of course, for fourcc values which spread > 'pixel' data across multiple storage units. > > Sorry for not reading the whole proposal up front; I've been out > crabbing in the San Juan's for a week and trying to catch up on email in > the last few days...
Really can't fault your choices there. > When I was doing Present, what I figured was that we'd define new kinds > of read-only picture which had image storage data associated with it > that could be in a non-pixel format -- various fourcc formats using > multiple buffers, jpeg, png or whatever. You could use those with Render > or Present to get data into RGB format or onto the screen. Trying to > mash them into 'pixmaps' makes little sense. > > In this case, I'd imagine we'd add fourcc pictures, and a new > DRI3PictureFromBuffers request. Adding a PresentPicture request would be > a nice bonus feature to make sure the copy was synchronized with vblank. Hm. I think I prefer Eric's suggestion, of just declaring this to be undefined behaviour. You're right that it makes little to no sense to mix the two, but I'm not sure what practical gain we get from expressing things as Pictures. Ultimately, the server still deals in Window Pixmaps and Screen Pixmaps for backing storage, and the compositor interface is NameWindowPixmap. Your suggestion of another type seems nicer, but it doesn't look like we can avoid Pixmaps as the lowest common denominator anyway. By implementation if not spec, DRI3 v1.0 enforces that depth 16 is RGB565, depth 24 is XRGB8888, and depth 32 is ARGB8888. Or at least in Mesa: the server only supports the latter two with glamor_egl. It seems like this has served well enough for long enough, so equally we could just eliminate the FourCC from the protocol, stick with the fixed depth <-> base format mapping, and encode that in the protocol text as well. That would much more clearly match the intention of the spec additions, which was to allow non-linearly-addressed (Intel X/Y*, Vivante tiled/supertiled, VC4 T-tiled, the infinite AMD/NV tiling modes) buffers, as well as losslessly-compressed buffers (Intel CCS, whatever Tegra calls its mode which similarly has an auxiliary buffer to interpret the tiled primary colour buffer, ARM AFBC which is just an inline block format). Allowing YUV buffers, attaching colourspace information (e.g. converting between primaries/EOTF), replacing the use of Pixmaps with another buffer type (Readable as a counterpart to Drawable ... ?), would all be objectively good things to have, but equally I don't think trying to fix them in a protocol which is really just a better version of PutImage for Pixmaps is the best thing. tl;dr: we could replace FourCC with depth as the format determinant to better match DRI3 v1.0, or just declare that doing anything with those Pixmaps other than displaying them to a Window with a compatible Visual results in undefined behaviour Cheers, Daniel _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel