[PATCH libdrm 3/3] util: Add SMPTE pattern support for C4 format

[Ilia Mirkin]

On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>
> Hi Ilia,
>
> On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> > > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> > > > index 953bf95492ee150c..42d75d700700dc3d 100644
> > > > --- a/tests/util/pattern.c
> > > > +++ b/tests/util/pattern.c
> > > > @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct util_rgb_info *rgb, void *mem,
> > > >  static unsigned int smpte_middle[7] = { 6, 7, 4, 7, 2, 7, 0 };
> > > >  static unsigned int smpte_bottom[8] = { 8, 9, 10, 7, 11, 7, 12, 7 };
> > > >
> > > > +static void write_pixel_4(uint8_t *mem, unsigned int x, unsigned int pixel)
> > > > +{
> > > > +       if (x & 1)
> > > > +               mem[x / 2] = (mem[x / 2] & 0xf0) | (pixel & 0x0f);
> > > > +       else
> > > > +               mem[x / 2] = (mem[x / 2] & 0x0f) | (pixel << 4);
> > > > +}
> > >
> > > The standard layout is MSB? i.e. first pixel goes in the upper bits of
> > > the first byte? It's been ages since I've dealt with C4 (or perhaps I
> > > never even touched it), but this seems a bit surprising.
> >
> > Exactly. All register documentation I've ever seen shows the MSB on
> > the left, i.e. for bytes:
> >
> >      MSB                         LSB
> >     +---+---+---+---+---+---+---+---+
> >     | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> >     +---+---+---+---+---+---+---+---+
> >
> > IBM used to count bits in the reverse order, but still had MSB left:
> >
> >      MSB                         LSB
> >     +---+---+---+---+---+---+---+---+
> >     | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
> >     +---+---+---+---+---+---+---+---+
> >
> > If the reverse ordering of pixels is ever needed, a new fourcc code can
> > be introduced.  Note that the fbdev API has support for both orderings
> > (see fb_bitfield.msb_right), but no driver ever sets msb_right = 1,
> > hence the fbdev core doesn't support it yet.
>
> Turns out I was wrong: fbdev ordering follows native ordering, and
> there's also FBINFO_FOREIGN_ENDIAN  :-(

I haven't double-checked the meaning in fbdev, but ENDIAN-ness
generally refers to the layout of *bytes*, not *bits*. Although one
could also argue that it's the layout of "elements", and so in that
way, upper/lower values could be considered flipped. I've never gone
that far though.

Cheers,

  -ilia