Hello Thomas, On 1/31/22 10:18, Thomas Zimmermann wrote: [snip] >> There are some hacks in the driver though. For example it exposes an XRGB8888 >> format even thought the OLED display is monochromatic and has 1 bit per pixel. >> >> The driver then goes and converts the XRGB8888 pixels first to grayscale and >> then to reverse mono. I took that idea from the repaper driver but that gives >> us the multiple copies that Geert was complaining about. > > This requires to update the console code for 1-bit BW output. The fbcon > side already supports this AFAIK. DRM's fbdev needs a few more branches > and something like a DRM_FORMAT_C1 fourcc. The XRGB8888 is really a > userspace requirement that is imposed by modern desktops. If DRM's > console has been updated, you could leave it out entirely. > > I could imagine that some simple userspace, such as Weston, comes with > support for palette formats and BW. Or there could be an entirely > separate program that puts graphics onto these displays. > Yes, I understand the rationale of why the repaper driver is doing that way but was just pointing out because Geert mentioned that is not efficient. Maybe in the meantime we can add a drm_fb_gray8_to_mono_reversed() helper to drivers/gpu/drm/drm_format_helper.c since there is more than one driver that does the same ? It's not a big issue for this device really since the I2C bus is slow anyways and the multiple copies are not a bottleneck AFAICT. I believe is worth to propose this driver as is and then try to optimize later. Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for now a DRM_MODE_CONNECTOR_Unknown. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
