On 03/05/17 12:06 AM, Gerd Hoffmann wrote:
Removing the definition also removes the possibility to describe a lot of pixel formats, so that should definitely be mentioned. I think it would also be good to have some kind of justified claim that no hardware actually needs the pixel formats this is removing (e.g. RGB565 BE).
That and RGB2101010 BE are the only candidates I can think of.
Dealing with those in none-native byteorder is a PITA though. Display hardware is little endian (pci byte order) for quite a while already.
Maybe by default, but not exclusively.
radeon looks differently on pre-R600 and R600+ hardware.
pre-R600 can byteswap on cpu access, so the cpu view is bigendian whereas things are actually stored on little endian byte order. Hardware supports both 16bit and 32bit swaps. Used for fbdev emulation (probably 32bit swaps, but not fully sure).
32-bit swaps for 32 bpp, 16-bit swaps for 16 bpp.
R600+ supports bigendian framebuffer formats, so no byteswapping on access is needed. Not sure whenever that includes 16bpp formats or whenever this is limited to the 8 bit-per-color formats [...]
It includes 16bpp. Looking at drivers/gpu/drm/radeon/atombios_crtc.c:dce4_crtc_do_set_base(), it sets up byte-swapping for all multi-byte formats, so it effectively treats all those formats as if they had DRM_FORMAT_BIG_ENDIAN set.
If the radeon (and amdgpu) driver were to be changed to use drm_mode_legacy_fb_format_he for >= R600, that must also handle 16 bpp, which requires DRM_FORMAT_BIG_ENDIAN. So I still don't see how that can be removed or even deprecated.
From Ilia's followup it sounds like there's a similar situation with
nouveau.