Hi Ville,
On Mon, Jul 11, 2022 at 2:17 PM Ville Syrjälä
<ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> On Fri, Jul 08, 2022 at 08:21:43PM +0200, Geert Uytterhoeven wrote:
> > Signed-off-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> > ---
> > Any better suggestion than appending "be"?
> >
> > v2:
> > - New.
> > --- a/tests/util/format.c
> > +++ b/tests/util/format.c
> > @@ -76,6 +76,9 @@ static const struct util_format_info format_info[] = {
> > { DRM_FORMAT_BGRX5551, "BX15", MAKE_RGB_INFO(5, 1, 5, 6, 5, 11, 0, 0) },
> > { DRM_FORMAT_RGB565, "RG16", MAKE_RGB_INFO(5, 11, 6, 5, 5, 0, 0, 0) },
> > { DRM_FORMAT_BGR565, "BG16", MAKE_RGB_INFO(5, 0, 6, 5, 5, 11, 0, 0) },
> > + /* Big-endian RGB16 */
> > + { DRM_FORMAT_XRGB1555 | DRM_FORMAT_BIG_ENDIAN, "XR15be", MAKE_RGB_INFO(5, 10, 5, 5, 5, 0, 0, 0) },
> > + { DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN, "RG16be", MAKE_RGB_INFO(5, 11, 6, 5, 5, 0, 0, 0) },
>
> How about just stripping the BE bit in util_format_info_find()
> so we don't have to duplicate the entries in the table?
There is no need to support big-endian variants of all formats.
E.g. big-endian [AX]RGB8888 just map to little-endian BGR[AX]8888.
XRGB1555 and RGB565 are probably the only RGB formats we care about.
Or perhaps some of the *30 formats?
> I guess util_format_fourcc() would end up being more a bit
> complicated since you'd have to massage the string.
True.
> But I'm not sure why we even store the fourcc as a string in
> the table anyway. Could just add some kind of string_to_fourcc()
> thingy instead AFAICS.
I guess that can be done.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
