[PATCH 07/11] drm/fbdevdrm: Add DRM <-> fbdev pixel-format conversion

[Thomas Zimmermann]

Hi

Am 26.03.19 um 17:29 schrieb Ville Syrjälä:
>> +
>> +static bool is_c8(const struct fb_info* fb_info)
>> +{
>> +	return fb_info->var.bits_per_pixel == 8;
>> +}
>> +
>> +static bool is_rgb565_be(const struct fb_info* fb_info)
>> +{
>> +	return (fb_info->var.bits_per_pixel == 16) &&
>> +	       (fb_info->var.red.offset == 0) &&
>> +	       (fb_info->var.red.length == 5) &&
>> +	       (fb_info->var.green.offset == 5) &&
>> +	       (fb_info->var.green.length == 6) &&
>> +	       (fb_info->var.blue.offset == 11) &&
>> +	       (fb_info->var.blue.length == 5);
>> +}
> 
> You can't distinguish LE vs. BE like this.
> 
> Maybe FBINFO_FOREIGN_ENDIAN is trustworthy?
> 

The test function means 'is the framebuffer in RGB565 format if the host
uses big-endian access'. Further below in the file, there are macros
that reverse the order of fields for little-endian hosts.

However, mapping all this to DRM formats is confusing.

According to the documentation, DRM_FORMAT_ is always in little-endian
format. But does that mean that the device uses little endian or that
the host uses little endian? If the device and the host disagree on
endianess, which takes precedence?

In the end, I tried different combinations of tests and DRM formats, and
checked the resulting output on the screen.

Best regards
Thomas

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190327/0e3ca06c/attachment.sig>