Hi Ilia, On Mon, Mar 14, 2022 at 2:44 PM Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: > On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > > On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: > > > > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> 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. Yes, usually it refers to the ordering of bytes in a word. Here, it's about the ordering of sub-byte pixels in a byte. Note that with C2 and C4, there's a third ordering that comes into play. So we have: 1. Ordering of bytes in a word, for bpp > 8, 2. Ordering of pixels in a byte, for bpp < 8, 3. Ordering of bits in a pixel, for bpp > 1. 1. Is handled by DRM_FORMAT_BIG_ENDIAN. 2. Is what we need to handle here. As bpp cannot be both < 8 and > 8, I think reusing DRM_FORMAT_BIG_ENDIAN is OK. 3. Is handled by fb_bitfield.msb_right, and always false (i.e. no driver ever set it). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds