[PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

[Keith Packard]

Eric Anholt <eric at anholt.net> writes:

> Note here that b8g8r8x8 couldn't be used with a depth 24 pixmap -- it's
> only advertised under 32 depth.  The r8g8b8 and x8r8g8b8 I believe
> internally are the same PictFormat, it's just advertised under both 24
> and 32bpp.  (picture.c's PictureCreateDefaultFormats() for reference)

Check xdpyinfo -ext RENDER:

  pict format:
	format id:    0x2b
	type:         Direct
	depth:        24
	alpha:         0 mask 0x0
	red:           0 mask 0xff
	green:         8 mask 0xff
	blue:         16 mask 0xff

...

  pict format:
	format id:    0x3a
	type:         Direct
	depth:        32
	alpha:         0 mask 0x0
	red:           0 mask 0xff
	green:         8 mask 0xff
	blue:         16 mask 0xff

And, of course all of these are 32bpp:

    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32

I'm not sure in what way these are the same?

> 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...

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.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170727/ebcdef80/attachment.sig>