[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWPQrErbMZ4wJPgROY7XOnKGvimNFg8JpiyuWqz2a3Gzw@mail.gmail.com>
Date: Mon, 14 Mar 2022 14:40:02 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Javier Martinez Canillas <javierm@...hat.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
Maxime Ripard <maxime@...no.tech>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
DRI Development <dri-devel@...ts.freedesktop.org>,
Noralf Trønnes <noralf@...nnes.org>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH 2/4] drm/format-helper: Add drm_fb_gray8_to_mono_reversed()
Hi Javier,
On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
<javierm@...hat.com> wrote:
> Add support to convert 8-bit grayscale to reversed monochrome for drivers
> that control monochromatic displays, that only have 1 bit per pixel depth.
>
> This helper function was based on repaper_gray8_to_mono_reversed() from
> the drivers/gpu/drm/tiny/repaper.c driver.
>
> Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
> return -EINVAL;
> }
> EXPORT_SYMBOL(drm_fb_blit_toio);
> +
> +/**
> + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
> + * @dst: reversed monochrome destination buffer
What's the meaning of "reversed"?
During the last few days, I've been balancing between (a) "reverse
video" and (b) "reverse bit order", but none of them seems to be true.
(a) The code maps 0-127 to 0 and 8-255 to 1, which just reduces from
256 to 2 grayscale levels, without inversion. The result is also
white-on-black on my ssd130x OLED.
(b) On little-endian, the CFB drawops use little-endian bit order,
which is what ends up in "byte" in the code below.
> + * @src: 8-bit grayscale source buffer
> + * @clip: Clip rectangle area to copy
> + *
> + * DRM doesn't have native monochrome or grayscale support.
> + * Such drivers can announce the commonly supported XR24 format to userspace
> + * and use drm_fb_xrgb8888_to_gray8() to convert to grayscale and then this
> + * helper function to convert to the native format.
> + */
> +void drm_fb_gray8_to_mono_reversed(void *dst, void *src, const struct drm_rect *clip)
> +{
> + size_t width = drm_rect_width(clip);
> + size_t height = drm_rect_width(clip);
> +
> + u8 *mono = dst, *gray8 = src;
> + unsigned int y, xb, i;
> +
> + for (y = 0; y < height; y++)
> + for (xb = 0; xb < width / 8; xb++) {
> + u8 byte = 0x00;
> +
> + for (i = 0; i < 8; i++) {
> + int x = xb * 8 + i;
> +
> + byte >>= 1;
> + if (gray8[y * width + x] >> 7)
> + byte |= BIT(7);
> + }
> + *mono++ = byte;
> + }
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
Powered by blists - more mailing lists