On Wed, Mar 27, 2019 at 09:28:49AM +0100, Thomas Zimmermann wrote:
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.
And that does not work. Wrong endianness swaps bytes, not components.
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?
It just means "the pixel value listed is stored in memory least significant byte first".
In the end, I tried different combinations of tests and DRM formats, and checked the resulting output on the screen.
This was just pointed out to me recently: https://github.com/afrantzis/pixel-format-guide
It seems to interpret drm formats correctly.
Though I wouldn't mind if someone improved the drm_fourcc.h docs since everyone except me seems to get confused by the current wording.