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@xxxxxxxxxx> 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@xxxxxxxxxx> > >> --- 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
