Hello Geert,

On 3/14/22 14:40, Geert Uytterhoeven wrote:

Hi Javier,

On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
[off-list ref] wrote:

quoted

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@redhat.com>

quoted

--- 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"?

Originally I took this helper from the repaper driver and it was called
repaper_gray8_to_mono_reversed(), so the naming just got carried over.

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.

As far as I understand is (a) from the options since the repaper display
uses black-on-white. But as you pointed out the ssd130x OLEDs instead do
white-on-black.

I should had probably just name the helper drm_fb_gray8_to_monochrome()
or maybe drm_fb_gray8_to_gray1() ?

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat