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 javierm@redhat.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@redhat.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"?
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() ?