Thanks @jimmo for the patch. At the very least the byte order of this RGB565 format should be documented, so that it's not a surprise when it comes out "reverse". But do you think it's worth an entire new format id and extra code to handle it? As an alternative, wouldn't it be possible to just provide (in Python, maybe in C...) an rgb-creation function rgb(r, g, b) which yields the right byte order for the given display?

OTOH, if/when we blit supports conversion of colour then it would need to know the precise RGB layout including byte order.

Also note that it might be possible to optimise your patch here (for code size and/or speed) by swapping the byte order of the incoming colour value, instead of using mp_binary_set_int().

Thanks Damien -- I can't quite see a nice way to support a conversion function (it's not clear whether it should live on the display or the framebuf, but like you say there are good reasons for putting it on the framebuf for blit/conversion etc - I was keen to work on this next). It's confusing for the programmer to ever see a "backwards" value, and it's a bit burdensome to have to remember when to flip the bytes (i.e. it's fine if I always use the rgb function, but what if my program has hardcoded values or perhaps loads RGB565 values from somewhere else).

To be honest I can't think of a reason why you'd ever not want BE, so for code size/speed I think I'd prefer to just retain the one mode and making it always BE... the current behaviour is surprising enough that maybe this would count as a bug fix rather than a breaking backwards-compatibility?

The two cases I can see for the current behaviour:

• You really care about accessing individual bytes in the framebuf for a purpose other than sending it directly to a display. I think at this point your code needs to be device-endian aware anyway.
• You're using a display that expects the bytes in LE -- I think this would be the case for adding RGB565_LE as a framebuffer mode.

@deshipu did you have any thoughts on this? When you added this mode which display were you using? Did you use an rgb() function that was device-endian aware?

I originally added that mode to handle ST7735, SSD1331, SSD1351 and ILI9341 displays — they all use the same endianness, some even allow you to change it. I have done much thinking about the general problem of handling displays — you can for example look at my pull request that adds a color mapping option to blit — but ultimately I concluded that framebuffer is the wrong approach to the particular problems of displaying user interfaces and games on the displays that already have their own memory, and I went with a completely different approach which uses a fraction of the memory and is much faster.

@peterhinch's comment on #2973 (comment) reminded me that I was still sitting on this...

I still feel the current behavior of framebuf.RGB565 is confusing, so I would like to fix this. Even if the display allows you to change its mode, then the (Python) driver needs to be aware of the host endianness etc.

Also note that it might be possible to optimise your patch here (for code size and/or speed) by swapping the byte order of the incoming colour value, instead of using mp_binary_set_int().

@dpgeorge I tried this and it made the code size larger (+8 bytes). But it would definitely be a speed improvement for all three methods (always for fill, and when the endianess matches for the other two). I've now included this change, happy to go back to the original mp_binary_set_int way though. (Overall this PR is +156 bytes).

I just want to bump this PR because I think that the framebuffer without big-little endiannes option is incomplete. I think that having an out-of-the-box solution for the cheapest display on the market, from my point of view, is much more important than every other mode implemented in framebuffer.

Discussion moving to #7253