[PATCH] Add m1bpp (monochrome, 1 bit/pixel) pixel format

[Drew DeVault]

On 2017-09-15  6:06 PM, Pekka Paalanen wrote:
> I'm sure you knew this, but you don't need this protocol addition just
> for driving the display. I guess you want this protocol addition so
> that you can write clients that draw directly in the 1-bit format so
> they don't waste 8x the memory (there are already 8-bit formats). The
> latter would be nice to mention in the commit message as it answers the
> "why".

Yes, your surmising is correct. I'll add it to the commit message.

> ((*((uint8_t *)row_begin + x / 8)) >> (7 - x % 8)) & 1
> 
> Is that correct, regardless of machine endianess?

Yes.

> I ask about endianess, because Pixman has some fun pixel formats where
> endianess is defined to affect also the order of bits, not just bytes.

This is such a format, and in theory the opposite endianness could
exist, though I've never observed it in practice. The language in the
description is sufficient to understand how to use this pixel format on
any particular architecture.

> Curious, given that drm_fourcc.h does not have any 1-bit formats
> defined, what kernel ABI does that display use?

This display doesn't have a kernel driver that I'm aware of. Most
applications drive it with GPIO.

> Indeed, 2 and 4 bit formats are also missing, but 8 and 16 bit ones are
> already defined unless you meant some new variation.

The 8 and 16 bit ones, so far as I can tell, are 8/16 bits per component
of an RGB(A) triple (quadruple), rather than 8/16 bits per pixel.