linux-kernel - Re: [PATCH v1 1/4] fbtft: Unorphan the driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 31 Jan 2022 11:18:57 +0100
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Thomas Zimmermann <tzimmermann@...e.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Andy Shevchenko <andy@...nel.org>, linux-fbdev@...r.kernel.org,
        Michael Hennerich <michael.hennerich@...log.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Helge Deller <deller@....de>, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Phillip Potter <phil@...lpotter.co.uk>,
        Carlis <zhangxuezhi1@...ong.com>,
        Lee Jones <lee.jones@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH v1 1/4] fbtft: Unorphan the driver

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