Re: [PATCH 2/2] dt-bindings: display: simple-framebuffer: Document mono format

[Sebastian Raase <basti@sraa.de>]

Hi,

On Thu, 12 Nov 2026 08:35:59 +0100
Thomas Zimmermann <tzimmermann@suse.de> wrote:

> Hi
> 
> Am 04.11.26 um 03:34 schrieb Sebastian Raase:
> > This is a 1 bit-per-pixel monochrome format, with 8 pixels/byte.
> >
> > Signed-off-by: Sebastian Raase <linux@sraa.de>
> > ---
> >   .../devicetree/bindings/display/simple-framebuffer.yaml         |
> > 2 ++ 1 file changed, 2 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> > b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> > index 45ffdebc9d86..c627ec088434 100644 ---
> > a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> > +++
> > b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> > @@ -94,6 +94,7 @@ properties: format: description: > Format of the
> > framebuffer:
> > +        * `mono` - 1-bit packed pixels, 8 pixels/byte  
> 
> I don't object the change, but I really object the naming.

I fully agree, but could not think of a better name at the time.

As Sashiko pointed out, "mono" neither describes the endianness nor the
polarity.

> Mono is not a good name because it doesn't describe the format's
> pixel layout. For example, RGB with only 2 colors is also mono in
> some sense.

A two-color RGB format sounds like a contradiction, although bi-color
LEDs are very common.

> The common names used in the Linux kernel for this type of color
> format are C1 and R1. More generally speaking,
> 
>   - Cn describes an n-bit format with a palette. The pixel bits index 
> into the palette.  Pixels are packed.
>   - Rn describes an n-bit format with a single color channel. The 
> channel has linear color gradient. Pixels are packed.
> 
> In your case, you'd define 'r1'. While at it, we can also define r2,
> r4, and r8.  The terminal supports up to 16 colors, so implementing
> r4 might be of interest to some simple hardware.

Sounds like a good idea; I can test those for simplefb (not simpledrm).
Do you have a suggestion on endianness and polarity in the name?

Today, we have grayscale/color in mind, so the obvious polarity is
0=dark and 1=bright. But the other approach uses 0=paper (white) and
1=ink (black), which leads to reverse video hardware. It's uncommon, so
we can probably ignore this.

Endianness is basically the same difference as RGBA vs. ABGR in 32-bit
color formats.

So far, I have only tried stride values which were multiples of 8, to
align them with byte boundaries. Any restriction would apply to r1, r2
and r4 formats.

If I send a v2 patch, should that be a follow-up of this email thread,
or a completely new thread?

> Best regards
> Thomas
> 
> 
> >           * `a1r5g5b5` - 16-bit pixels, d[15]=a, d[14:10]=r,
> > d[9:5]=g, d[4:0]=b
> >           * `a2r10g10b10` - 32-bit pixels, d[31:30]=a, d[29:20]=r,
> > d[19:10]=g, d[9:0]=b
> >           * `a8b8g8r8` - 32-bit pixels, d[31:24]=a, d[23:16]=b,
> > d[15:8]=g, d[7:0]=r @@ -106,6 +107,7 @@ properties:
> >           * `x8r8g8b8` - 32-bit pixels, d[23:16]=r, d[15:8]=g,
> > d[7:0]=b
> >           * `x8b8g8r8` - 32-bit pixels, d[23:16]=b, d[15:8]=g,
> > d[7:0]=r enum:
> > +      - mono
> >         - a1r5g5b5
> >         - a2r10g10b10
> >         - a8b8g8r8  

Best Regards,
Sebastian