On 2022-07-11 14:34, Geert Uytterhoeven wrote:
> 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'd say all of those, and any other formats with components straddling byte boundaries (including formats with multi-byte components).
P.S. libdrm changes are now reviewed and merged as GitLab merge requests: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests
I guess CONTRIBUTING.rst could make this clearer.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
