| Message ID | cc84f1fcd0901ba58a2e4fd34c43846c622fd157.1646683737.git.geert@linux-m68k.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add support for low-color frame buffer formats | expand |
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); > + 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.
Hi Ilia, 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); > > + 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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
Hi Ilia, 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); > > > + 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'll reply to the thread that introduced the format. https://lore.kernel.org/all/8d3c0cc370b0214244b01a64c588e5e506531716.1646683502.git.geert@linux-m68k.org/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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
On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Ilia, > > 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); > > > > + 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
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); > > > > > + 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@linux-m68k.org 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
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); > > > > > > + 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. 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
Hi Ilia, On Mon, Mar 14, 2022 at 3:39 PM Ilia Mirkin <imirkin@alum.mit.edu> wrote: > On Mon, Mar 14, 2022 at 10:06 AM Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > 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); > > > > > > > + 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. > > > > 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. > > 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. I'm fully aware the DRM_FORMAT_BIG_ENDIAN flag is broken, and it's on my list of things to fix (for 16-bpp Atari). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index e369044fb7a484c1..205b7093b0045e01 100644 --- a/tests/modetest/modetest.c +++ b/tests/modetest/modetest.c @@ -1122,16 +1122,21 @@ static void set_gamma(struct device *dev, unsigned crtc_id, unsigned fourcc) struct drm_color_lut gamma_lut[256]; int i, ret; - if (fourcc == DRM_FORMAT_C8) { - /* TODO: Add C8 support for more patterns */ + switch (fourcc) { + case DRM_FORMAT_C4: + case DRM_FORMAT_C8: + /* TODO: Add index support for more patterns */ util_smpte_index_gamma(256, gamma_lut); drmModeCreatePropertyBlob(dev->fd, gamma_lut, sizeof(gamma_lut), &blob_id); - } else { + break; + + default: for (i = 0; i < 256; i++) { gamma_lut[i].red = gamma_lut[i].green = gamma_lut[i].blue = i << 8; } + break; } add_property_optional(dev, crtc_id, "DEGAMMA_LUT", 0); 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); +} + +static void fill_smpte_c4(void *mem, unsigned int width, unsigned int height, + unsigned int stride) +{ + unsigned int x; + unsigned int y; + + for (y = 0; y < height * 6 / 9; ++y) { + for (x = 0; x < width; ++x) + write_pixel_4(mem, x, x * 7 / width); + mem += stride; + } + + for (; y < height * 7 / 9; ++y) { + for (x = 0; x < width; ++x) + write_pixel_4(mem, x, smpte_middle[x * 7 / width]); + mem += stride; + } + + for (; y < height; ++y) { + for (x = 0; x < width * 5 / 7; ++x) + write_pixel_4(mem, x, + smpte_bottom[x * 4 / (width * 5 / 7)]); + for (; x < width * 6 / 7; ++x) + write_pixel_4(mem, x, + smpte_bottom[(x - width * 5 / 7) * 3 / + (width / 7) + 4]); + for (; x < width; ++x) + write_pixel_4(mem, x, smpte_bottom[7]); + mem += stride; + } +} + static void fill_smpte_c8(void *mem, unsigned int width, unsigned int height, unsigned int stride) { @@ -688,6 +728,8 @@ static void fill_smpte(const struct util_format_info *info, void *planes[3], unsigned char *u, *v; switch (info->format) { + case DRM_FORMAT_C4: + return fill_smpte_c4(planes[0], width, height, stride); case DRM_FORMAT_C8: return fill_smpte_c8(planes[0], width, height, stride); case DRM_FORMAT_UYVY:
Add support for drawing the SMPTE pattern in a buffer using the C4 indexed format. Note that this still uses 256 instead of 16 as the CLUT size, as DRM_IOCTL_MODE_SETGAMMA enforces that the size matches against the (fixed) gamma size, while the CLUT size depends on the format. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- The linuxdoc comments say userspace can query the gamma size: * drm_mode_gamma_set_ioctl - set the gamma table * * Set the gamma table of a CRTC to the one passed in by the user. Userspace can * inquire the required gamma table size through drm_mode_gamma_get_ioctl. * drm_mode_gamma_get_ioctl - get the gamma table * * Copy the current gamma table into the storage provided. This also provides * the gamma table size the driver expects, which can be used to size the * allocated storage. but the code doesn't seem to support that in an easy way (like setting red/green/blue to NULL on input, retrieving gamma_size on output), only by providing big enough buffers for red/green/blue, and looping over gamma_size until -EINVAL is no longer returned. --- tests/modetest/modetest.c | 11 +++++++--- tests/util/pattern.c | 42 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 3 deletions(-)