Re: [PATCH weston 01/68] libweston: Add pixel-format helpers
On Mon, 13 Feb 2017 18:24:58 +
Daniel Stone wrote:
> Hi,
>
> On 14 December 2016 at 15:59, Pekka Paalanen wrote:
> > On Fri, 9 Dec 2016 19:57:16 +
> > Daniel Stone wrote:
> >> + {
> >> + .format = DRM_FORMAT_RGBX,
> >> + .gl_format = GL_RGBA,
> >> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
> >
> > Could there be any concern about sampling garbage as alpha?
> > Should we have a flag 'ignore_alpha'?
>
> I could add an explicit .you_must_ignore_alpha_no_im_serious = 1 to
> opaque formats, but given that there's already a helper to query
> whether or not the format is opaque, it seems a bit overkill.
Ah yes, I missed that point. Very good, although it assumes that all
non-opaque formats do have an opaque substitute, which fails on AYUV.
> >> + {
> >> + .format = DRM_FORMAT_BGRX,
> >> + .gl_format = GL_BGRA_EXT,
> >> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
> >> + },
> >> + {
> >> + .format = DRM_FORMAT_BGRA,
> >> + .opaque_substitute = DRM_FORMAT_BGRX,
> >> + .gl_format = GL_BGRA_EXT,
> >> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
> >> + },
>
> Turns out that BGRA_EXT is only considered valid for UNSIGNED_BYTE, so
> I've axed all users of BGRA_EXT except for ARGB/XRGB.
D'oh.
> >> + {
> >> + .format = DRM_FORMAT_BGR888,
> >> + .gl_type = GL_RGB,
> >> + .gl_format = GL_UNSIGNED_BYTE,
> >
> > How do the 24-bpp formats actually work? Do we really imagine there is
> > a 24-bit word and then address the bits of that?
> >
> > Yes, I'm thinking about big-endian.
>
> Not a word as such. To the very best of my understanding,
> UNSIGNED_BYTE loads each component in left-to-right order (in this
> case, R then G then B) one byte at a time, starting from lower to
> higher memory address. IOW, GL_RGB + GL_UNSIGNED_BYTE will always,
> regardless of endianness, load DRM_FORMAT_BGR888 as defined to be
> little-endian.
Yes, the GL side is clear. The unclear part was DRM_FORMAT_BGR888 which
is defined as little-endian, but since there is no such thing as a
24-bit word, what does "little-endian" mean in that case?
#define DRM_FORMAT_BGR888 fourcc_code('B', 'G', '2', '4') /* [23:0] B:G:R
little endian */
I think that actually tries to say that there is a 24-bit word, which
is kind of like a 32-bit word for the byte order, except bits 24-31 do
not exist.
Yeah, hair-splitting, mostly on how the DRM description should be read.
> >> + {
> >> + .format = DRM_FORMAT_XRGB,
> >> + .depth = 24,
> >> + .bpp = 32,
> >> + .gl_format = GL_BGRA_EXT,
> >> + .gl_type = GL_UNSIGNED_BYTE,
> >
> > GL info incorrect for big-endian.
>
> As above, I don't believe that to be the case.
I think you're right. DRM formats are always explicitly little-endian
regardless of the machine endianess. I was probably mislead by Pixman
formats which are machine-endian.
IOW, Pixman <-> DRM format conversion depends on machine endianess.
That makes drm_output_init_pixman() in upstream master broken for
big-endian, because the translation from GBM formats (identical to DRM
formats, except GBM_BO formats??) to Pixman formats does not take
machine endianess into account.
That actually raises a fun question about wl_shm formats. If Pixman
formats are machine-endian, and wl_shm formats are like DRM formats
little-endian, what happens with CAIRO_FORMAT_ARGB32 drawing?
https://www.cairographics.org/manual/cairo-Image-Surfaces.html#cairo-format-t
says it's machine-endian.
I.e. Cairo on big-endian may not work with wl_shm, because the format
is not the ones guaranteed to work in the protocol spec or
libwayland-server.
IOW, Pixman <-> wl_shm format conversion depends on machine endianess.
Or, are the special format codes WL_SHM_FORMAT_ARGB and
WL_SHM_FORMAT_XRGB machine-endian unlike everything else?
If these were originally designed to match Cairo formats, these would
need to be machine-endian!
> >> + },
> >> + {
> >> + .format = DRM_FORMAT_ARGB,
> >> + .opaque_substitute = DRM_FORMAT_XRGB,
> >> + .depth = 32,
> >> + .bpp = 32,
> >> + .gl_format = GL_BGRA_EXT,
> >> + .gl_type = GL_UNSIGNED_BYTE,
> >
> > GL info incorrect for big-endian.
> >
> > Well, yeah, you know.
> >
> > < daniels> happy to drop a #if __BYTE_ORDER__ == BIG_ENDIAN #error
> >reverse literally every single one of these #endif in there
> >
> > Please do. :-)
>
> I went with a different approach; see below. (Also note that
> gl-renderer is absolutely broken _today_ if this is the case, since it
> maps ARGB -> GL_BGRA_EXT + GL_UNSIGNED_BYTE without regard to
> endianness. But I don't think it is, as above.)
Yeah, seeing there actually are people using big-endian still
( https://bu
Re: [PATCH weston 01/68] libweston: Add pixel-format helpers
Hi,
On 14 December 2016 at 15:59, Pekka Paalanen wrote:
> On Fri, 9 Dec 2016 19:57:16 +
> Daniel Stone wrote:
>> + {
>> + .format = DRM_FORMAT_RGBX,
>> + .gl_format = GL_RGBA,
>> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
>
> Could there be any concern about sampling garbage as alpha?
> Should we have a flag 'ignore_alpha'?
I could add an explicit .you_must_ignore_alpha_no_im_serious = 1 to
opaque formats, but given that there's already a helper to query
whether or not the format is opaque, it seems a bit overkill.
>> + {
>> + .format = DRM_FORMAT_BGRX,
>> + .gl_format = GL_BGRA_EXT,
>> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
>> + },
>> + {
>> + .format = DRM_FORMAT_BGRA,
>> + .opaque_substitute = DRM_FORMAT_BGRX,
>> + .gl_format = GL_BGRA_EXT,
>> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
>> + },
Turns out that BGRA_EXT is only considered valid for UNSIGNED_BYTE, so
I've axed all users of BGRA_EXT except for ARGB/XRGB.
>> + {
>> + .format = DRM_FORMAT_BGR888,
>> + .gl_type = GL_RGB,
>> + .gl_format = GL_UNSIGNED_BYTE,
>
> How do the 24-bpp formats actually work? Do we really imagine there is
> a 24-bit word and then address the bits of that?
>
> Yes, I'm thinking about big-endian.
Not a word as such. To the very best of my understanding,
UNSIGNED_BYTE loads each component in left-to-right order (in this
case, R then G then B) one byte at a time, starting from lower to
higher memory address. IOW, GL_RGB + GL_UNSIGNED_BYTE will always,
regardless of endianness, load DRM_FORMAT_BGR888 as defined to be
little-endian.
>> + {
>> + .format = DRM_FORMAT_XRGB,
>> + .depth = 24,
>> + .bpp = 32,
>> + .gl_format = GL_BGRA_EXT,
>> + .gl_type = GL_UNSIGNED_BYTE,
>
> GL info incorrect for big-endian.
As above, I don't believe that to be the case.
>> + },
>> + {
>> + .format = DRM_FORMAT_ARGB,
>> + .opaque_substitute = DRM_FORMAT_XRGB,
>> + .depth = 32,
>> + .bpp = 32,
>> + .gl_format = GL_BGRA_EXT,
>> + .gl_type = GL_UNSIGNED_BYTE,
>
> GL info incorrect for big-endian.
>
> Well, yeah, you know.
>
> < daniels> happy to drop a #if __BYTE_ORDER__ == BIG_ENDIAN #error
>reverse literally every single one of these #endif in there
>
> Please do. :-)
I went with a different approach; see below. (Also note that
gl-renderer is absolutely broken _today_ if this is the case, since it
maps ARGB -> GL_BGRA_EXT + GL_UNSIGNED_BYTE without regard to
endianness. But I don't think it is, as above.)
>> + {
>> + .format = DRM_FORMAT_ARGB2101010,
>> + .opaque_substitute = DRM_FORMAT_XRGB2101010,
>> + .gl_type = GL_BGRA_EXT,
>> + .gl_format = GL_UNSIGNED_INT_2_10_10_10_REV_EXT,
>
> I suspect the GL format is not right...
>
> "The elements in a reversed packed pixel are ordered such that the
> first element is in the least-significant bits, ..."
>
> So, B would be the 2 LSB, G the next higher 10 bits, etc.
>
> The DRM format says A is the 2 MSB, right? That would make
> GL_UNSIGNED_INT_2_10_10_10_EXT for the bits, and GL_ARGB for the order
> (which might not exist?).
>
> Or, GL_UNSIGNED_INT_10_10_10_2_REV (does this exist?) and GL_BGRA_EXT.
Mind you, BGRA_EXT can't be used for anything other than
UNSIGNED_BYTE, so I just axed the GL equivalence for all the 10bpc
formats as there is none. You're right that the format definition was
confused even if this were the case though.
>> + {
>> + .format = DRM_FORMAT_YUYV,
>> + .sampler_type = EGL_TEXTURE_Y_XUXV_WL,
>> + .num_planes = 1,
>> + .hsub = 2,
>
> Should chroma_order and luma_chroma_order be set? I suppose 0 happens
> to be a right value and it gets written implicitly.
Exactly.
>> + },
>> + {
>> + .format = DRM_FORMAT_YVYU,
>> + .sampler_type = EGL_TEXTURE_Y_XUXV_WL,
>> + .num_planes = 1,
>> + .chroma_order = ORDER_VU,
>> + .hsub = 2,
>
> Should these entries have also all the information we now have in the
> yuv_formats table in gl-renderer.c?
What in particular do you feel it's missing? Per-plane subsampling values?
>> +WL_EXPORT bool
>> +pixel_format_is_opaque(const struct pixel_format_info *info)
>> +{
>> + return !!info->opaque_substitute;
>
> Um, if there is an opaque substitute, you say the original format is
> opaque?
> Shouldn't it be the opposite? And even then I'm not sure it's accurate.
You're right that it's currently inverted, but when fixed, this only
returns incorrect information for AYUV (IIRC). But AYUV isn't actually
supported, so ...
>> +WL_EXPORT const struct pixel_format_info *
>> +pixel_format_get_opaque_substi
Re: [PATCH weston 01/68] libweston: Add pixel-format helpers
On Fri, 9 Dec 2016 19:57:16 +
Daniel Stone wrote:
> Rather than duplicating knowledge of pixel formats across several
> components, create a custom central repository.
>
> Signed-off-by: Daniel Stone
>
> Differential Revision: https://phabricator.freedesktop.org/D1511
> ---
> libweston/pixel-formats.c | 398
> ++
> libweston/pixel-formats.h | 112 +
> 2 files changed, 510 insertions(+)
> create mode 100644 libweston/pixel-formats.c
> create mode 100644 libweston/pixel-formats.h
>
> diff --git a/libweston/pixel-formats.c b/libweston/pixel-formats.c
> new file mode 100644
> index 000..9c70e73
> --- /dev/null
> +++ b/libweston/pixel-formats.c
> @@ -0,0 +1,398 @@
> +/*
> + * Copyright © 2016 Collabora, Ltd.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Author: Daniel Stone
> + */
> +
> +#include "config.h"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "helpers.h"
> +#include "wayland-util.h"
> +#include "pixel-formats.h"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "weston-egl-ext.h"
> +
> +/**
> + * Table of DRM formats supported by Weston; RGB, ARGB and YUV formats are
> + * supported. Indexed/greyscale formats, and formats not containing complete
> + * colour channels, are not supported.
> + */
> +static const struct pixel_format_info pixel_format_table[] = {
> + {
> + .format = DRM_FORMAT_XRGB,
> + },
> + {
> + .format = DRM_FORMAT_ARGB,
> + .opaque_substitute = DRM_FORMAT_XRGB,
> + },
> + {
> + .format = DRM_FORMAT_XBGR,
> + },
> + {
> + .format = DRM_FORMAT_ABGR,
> + .opaque_substitute = DRM_FORMAT_XBGR,
> + },
> + {
> + .format = DRM_FORMAT_RGBX,
> + .gl_format = GL_RGBA,
> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
Could there be any concern about sampling garbage as alpha?
Should we have a flag 'ignore_alpha'?
> + },
> + {
> + .format = DRM_FORMAT_RGBA,
> + .opaque_substitute = DRM_FORMAT_RGBX,
> + .gl_format = GL_RGBA,
> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
> + },
> + {
> + .format = DRM_FORMAT_BGRX,
> + .gl_format = GL_BGRA_EXT,
> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
> + },
> + {
> + .format = DRM_FORMAT_BGRA,
> + .opaque_substitute = DRM_FORMAT_BGRX,
> + .gl_format = GL_BGRA_EXT,
> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
> + },
> + {
> + .format = DRM_FORMAT_XRGB1555,
> + .depth = 15,
> + .bpp = 16,
> + },
> + {
> + .format = DRM_FORMAT_ARGB1555,
> + .opaque_substitute = DRM_FORMAT_XRGB1555,
> + },
> + {
> + .format = DRM_FORMAT_XBGR1555,
> + },
> + {
> + .format = DRM_FORMAT_ABGR1555,
> + .opaque_substitute = DRM_FORMAT_XBGR1555,
> + },
> + {
> + .format = DRM_FORMAT_RGBX5551,
> + .gl_format = GL_RGBA,
> + .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
> + },
> + {
> + .format = DRM_FORMAT_RGBA5551,
> + .opaque_substitute = DRM_FORMAT_RGBX5551,
> + .gl_format = GL_RGBA,
> + .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
> + },
> + {
> + .format = DRM_FORMAT_BGRX5551,
> + .gl_format = GL_BGRA_EXT,
> + .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
> + },
> + {
> + .format = DRM_FORMAT_BGRA5551,
> + .opaque_substitute = DRM_FORMAT_BGRX5551,
> + .gl_format = GL_BGRA_EXT,
> + .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
> + }
Re: Fwd: [PATCH weston 01/68] libweston: Add pixel-format helpers
On 09.12.2016 22:30, Daniel Stone wrote: > Hi, > Hi, > On 9 December 2016 at 20:37, Armin Krezović wrote: >> On 09.12.2016 20:57, Daniel Stone wrote: >>> libweston/pixel-formats.c | 398 >>> ++ >>> libweston/pixel-formats.h | 112 + >> >> Where are corresponding build system modifications? > > Missing, apparently ... :\ > >>> +#include >>> +#include >>> +#include >>> +#include >> >> Is it supposed to work without EGL/GLESv2 enabled? > > Not really, no; note that the DRM backend has a hard dependency on GBM > and the Wayland backend has a hard dependency on libwayland-egl, so > this only really affects people building the X11/headless backends > only with no EGL. I suppose we could do a giant #ifdef tree, or just > pull all the tokens we use into weston-egl-ext.h and use that. Do you > have any preferences? > Well, if my guess is correct, this is supposed to be part of libweston, no? I don't think some people would like to have hard EGL dep on libweston itself, and conditionally building this into the library might produce incompatible lib with and without --disable-egl using the same source. That said, I'm all for importing the needed bits into weston-egl-ext.h (if you prefer to #ifdef a lot, go ahead). >>> +/** >>> + * Table of DRM formats supported by Weston; RGB, ARGB and YUV formats are >>> + * supported. Indexed/greyscale formats, and formats not containing >>> complete >>> + * colour channels, are not supported. >>> + */ >> >> I expected something using this immediately. I suggest you squash it with >> something >> else that uses this. > > It could be squashed with 'Store format in drm_fb', but as the > DRM-specific parts of the series were getting very little review, and > it can also be useful for gl-renderer's SHM uploads in particular, I > didn't want to muddle it in with the rest of the series. Depending on > how that goes (whether I get to porting gl-renderer, if earlier parts > of the series get reviewed so we can merge this, etc), it can be > squashed into its first user. > Well, you could've squashed it into that patch and sent it (from what I've seen it doesn't involve any new code and doesn't depend on anything else), and I can help you with review and gl-renderer porting, as this can be landed independently from rest of the series. Even if they don't fit together, at least make the patch that uses this a next one, so someone can take a look at example usage without having to dig through whole series to find out what is using this. > Cheers, > Daniel > signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Fwd: [PATCH weston 01/68] libweston: Add pixel-format helpers
Hi, On 9 December 2016 at 20:37, Armin Krezović wrote: > On 09.12.2016 20:57, Daniel Stone wrote: >> libweston/pixel-formats.c | 398 >> ++ >> libweston/pixel-formats.h | 112 + > > Where are corresponding build system modifications? Missing, apparently ... :\ >> +#include >> +#include >> +#include >> +#include > > Is it supposed to work without EGL/GLESv2 enabled? Not really, no; note that the DRM backend has a hard dependency on GBM and the Wayland backend has a hard dependency on libwayland-egl, so this only really affects people building the X11/headless backends only with no EGL. I suppose we could do a giant #ifdef tree, or just pull all the tokens we use into weston-egl-ext.h and use that. Do you have any preferences? >> +/** >> + * Table of DRM formats supported by Weston; RGB, ARGB and YUV formats are >> + * supported. Indexed/greyscale formats, and formats not containing complete >> + * colour channels, are not supported. >> + */ > > I expected something using this immediately. I suggest you squash it with > something > else that uses this. It could be squashed with 'Store format in drm_fb', but as the DRM-specific parts of the series were getting very little review, and it can also be useful for gl-renderer's SHM uploads in particular, I didn't want to muddle it in with the rest of the series. Depending on how that goes (whether I get to porting gl-renderer, if earlier parts of the series get reviewed so we can merge this, etc), it can be squashed into its first user. Cheers, Daniel signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 01/68] libweston: Add pixel-format helpers
On 09.12.2016 20:57, Daniel Stone wrote: > Rather than duplicating knowledge of pixel formats across several > components, create a custom central repository. > Hi, > Signed-off-by: Daniel Stone > > Differential Revision: https://phabricator.freedesktop.org/D1511 > --- > libweston/pixel-formats.c | 398 > ++ > libweston/pixel-formats.h | 112 + > 2 files changed, 510 insertions(+) > create mode 100644 libweston/pixel-formats.c > create mode 100644 libweston/pixel-formats.h > Where are corresponding build system modifications? > diff --git a/libweston/pixel-formats.c b/libweston/pixel-formats.c > new file mode 100644 > index 000..9c70e73 > --- /dev/null > +++ b/libweston/pixel-formats.c > @@ -0,0 +1,398 @@ > +/* > + * Copyright © 2016 Collabora, Ltd. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the next > + * paragraph) shall be included in all copies or substantial portions of the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. > + * > + * Author: Daniel Stone > + */ > + > +#include "config.h" > + > +#include > +#include > +#include > +#include > + > +#include "helpers.h" > +#include "wayland-util.h" > +#include "pixel-formats.h" > + > +#include > +#include > +#include > +#include > + Is it supposed to work without EGL/GLESv2 enabled? > +#include "weston-egl-ext.h" > + > +/** > + * Table of DRM formats supported by Weston; RGB, ARGB and YUV formats are > + * supported. Indexed/greyscale formats, and formats not containing complete > + * colour channels, are not supported. > + */ I expected something using this immediately. I suggest you squash it with something else that uses this. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 01/68] libweston: Add pixel-format helpers
Rather than duplicating knowledge of pixel formats across several
components, create a custom central repository.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1511
---
libweston/pixel-formats.c | 398 ++
libweston/pixel-formats.h | 112 +
2 files changed, 510 insertions(+)
create mode 100644 libweston/pixel-formats.c
create mode 100644 libweston/pixel-formats.h
diff --git a/libweston/pixel-formats.c b/libweston/pixel-formats.c
new file mode 100644
index 000..9c70e73
--- /dev/null
+++ b/libweston/pixel-formats.c
@@ -0,0 +1,398 @@
+/*
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Daniel Stone
+ */
+
+#include "config.h"
+
+#include
+#include
+#include
+#include
+
+#include "helpers.h"
+#include "wayland-util.h"
+#include "pixel-formats.h"
+
+#include
+#include
+#include
+#include
+
+#include "weston-egl-ext.h"
+
+/**
+ * Table of DRM formats supported by Weston; RGB, ARGB and YUV formats are
+ * supported. Indexed/greyscale formats, and formats not containing complete
+ * colour channels, are not supported.
+ */
+static const struct pixel_format_info pixel_format_table[] = {
+ {
+ .format = DRM_FORMAT_XRGB,
+ },
+ {
+ .format = DRM_FORMAT_ARGB,
+ .opaque_substitute = DRM_FORMAT_XRGB,
+ },
+ {
+ .format = DRM_FORMAT_XBGR,
+ },
+ {
+ .format = DRM_FORMAT_ABGR,
+ .opaque_substitute = DRM_FORMAT_XBGR,
+ },
+ {
+ .format = DRM_FORMAT_RGBX,
+ .gl_format = GL_RGBA,
+ .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
+ },
+ {
+ .format = DRM_FORMAT_RGBA,
+ .opaque_substitute = DRM_FORMAT_RGBX,
+ .gl_format = GL_RGBA,
+ .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
+ },
+ {
+ .format = DRM_FORMAT_BGRX,
+ .gl_format = GL_BGRA_EXT,
+ .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
+ },
+ {
+ .format = DRM_FORMAT_BGRA,
+ .opaque_substitute = DRM_FORMAT_BGRX,
+ .gl_format = GL_BGRA_EXT,
+ .gl_type = GL_UNSIGNED_SHORT_4_4_4_4,
+ },
+ {
+ .format = DRM_FORMAT_XRGB1555,
+ .depth = 15,
+ .bpp = 16,
+ },
+ {
+ .format = DRM_FORMAT_ARGB1555,
+ .opaque_substitute = DRM_FORMAT_XRGB1555,
+ },
+ {
+ .format = DRM_FORMAT_XBGR1555,
+ },
+ {
+ .format = DRM_FORMAT_ABGR1555,
+ .opaque_substitute = DRM_FORMAT_XBGR1555,
+ },
+ {
+ .format = DRM_FORMAT_RGBX5551,
+ .gl_format = GL_RGBA,
+ .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
+ },
+ {
+ .format = DRM_FORMAT_RGBA5551,
+ .opaque_substitute = DRM_FORMAT_RGBX5551,
+ .gl_format = GL_RGBA,
+ .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
+ },
+ {
+ .format = DRM_FORMAT_BGRX5551,
+ .gl_format = GL_BGRA_EXT,
+ .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
+ },
+ {
+ .format = DRM_FORMAT_BGRA5551,
+ .opaque_substitute = DRM_FORMAT_BGRX5551,
+ .gl_format = GL_BGRA_EXT,
+ .gl_type = GL_UNSIGNED_SHORT_5_5_5_1,
+ },
+ {
+ .format = DRM_FORMAT_RGB565,
+ .depth = 16,
+ .bpp = 16,
+ .gl_type = GL_RGB,
+ .gl_type = GL_UNSIGNED_SHORT_5_6_5,
+ },
+ {
+ .format = DRM_FORMAT_BGR565,
+ },
+ {
+
