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

[Michel Dänzer]

On 28/07/17 07:39 PM, Daniel Stone wrote:
> On 28 July 2017 at 09:54, Michel Dänzer <michel at daenzer.net> wrote:
>> On 28/07/17 05:03 PM, Daniel Stone wrote:
>>> By implementation if not spec, DRI3 v1.0 enforces that depth 16 is
>>> RGB565, depth 24 is XRGB8888, and depth 32 is ARGB8888.
>>
>> No, it doesn't. How the bits stored in a pixmap are interpreted is
>> outside of the scope of DRI3 1.0.
> 
> I mean that, when using glamor_egl and Mesa, PixmapFromBuffer
> translates XRGB8888 to depth 24, and BufferFromPixmap translates depth
> 24 to XRGB8888. So, de facto, these are the established translations
> between depth and format required to use DRI3.

That's just a glamor implementation detail, nothing more.

At the risk of sounding like a broken record, a pixmap is merely a
container for storing an integer of n bits per pixel, where n is the
pixmap depth. How those integer values are interpreted isn't defined by
the pixmap itself but only by something else, e.g. the visual of a
window or the format of a picture.

A client which uses the DRI3 and Present extensions for direct rendering
has to use the format matching the window visual for rendering to the
back buffer shared with the server, otherwise the window will display
garbage. But as long as the client uses the correct format, things will
work out correctly no matter which format glamor (or any other
implementation) uses for X11 core drawing with drawables of that depth.


>>> 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
>>
>> I'm getting less and less convinced that any reference at all to formats
>> in the context of pixmaps in the DRI3 specification is a good idea.
> 
> I'd be fine with that, but at least documenting the implemented
> behaviour would probably be reasonable, to save other implementations
> from having to reverse-engineer the actual semantics.

I think it's pretty clear by now from this thread that talking about
formats at all in the context of pixmaps rather confuses things (and
even people who have been working with X for a long time).


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer