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:28:23 +0100
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Javier Martinez Canillas <javierm@...hat.com>,
        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

Hi

Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas:
> 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.

It's a fair point, I think. People are concerned about resource 
consumption on low-end devices.

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

Sure.

> 
> 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.

Absolutely. If you post a cleaned-up version of the patch, I'd take a look.

> 
> Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for
> now a DRM_MODE_CONNECTOR_Unknown.

That might have implications on userspace. Maybe ask around. (Not that 
we actually run userspace on the device).

Best regards
Thomas

> 
> Best regards,

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)