On Mon, Mar 14, 2022 at 10:06 AM Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi Ilia,
On Mon, Mar 14, 2022 at 2:44 PM Ilia Mirkin imirkin@alum.mit.edu wrote:
On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin imirkin@alum.mit.edu wrote:
On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven geert@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);elsemem[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:
Ordering of bytes in a word, for bpp > 8,
Ordering of pixels in a byte, for bpp < 8,
Ordering of bits in a pixel, for bpp > 1.
Is handled by DRM_FORMAT_BIG_ENDIAN.
OK. Note that DRM_FORMAT_BIG_ENDIAN flag for formats other than RGBX8888 and very similar formats is basically broken in drm. So ... watch out. There are two setups supported for big-endian currently:
1. Legacy: radeon/nouveau, ignore the "little endian" comment about formats and only supports AddFB, not AddFB2. The former only has depth/bpp, not the actual format, anyways. This matches what current user-space expects too. (quirk_addfb_prefer_host_byte_order = 1) 2. AddFB2 support with proper formats. Only used for vmwgfx and virgl in practice for BE, IIRC. Only supports 32-bit 8bpc formats, and uses some helpers to just flip around DRM_FORMAT_BIG_ENDIAN bit to an equivalent format in the frontend api handling. This obviously won't work for other formats, but none of the helpers are ready to receive the BIG_ENDIAN bit.
Cheers,
-ilia