Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <840ec74d-60c6-9480-709c-8cd597c6f5b0@redhat.com>
Date:   Mon, 31 Jan 2022 11:18:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH v1 1/4] fbtft: Unorphan the driver
Content-Language: en-US
To:     Thomas Zimmermann <tzimmermann@suse.de>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Andy Shevchenko <andy@kernel.org>, linux-fbdev@vger.kernel.org,
        Michael Hennerich <michael.hennerich@analog.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Helge Deller <deller@gmx.de>, linux-staging@lists.linux.dev,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        Phillip Potter <phil@philpotter.co.uk>,
        Carlis <zhangxuezhi1@yulong.com>,
        Lee Jones <lee.jones@linaro.org>,
        Heiner Kallweit <hkallweit1@gmail.com>
References: <20220125202118.63362-1-andriy.shevchenko@linux.intel.com>
 <20220125202118.63362-2-andriy.shevchenko@linux.intel.com>
 <YfEG2qVO9K9G+g1d@kroah.com>
 <CAKMK7uGoRC9a4cMCADTipV67oivfWvTw=6RYm2kOthB_bhWnXQ@mail.gmail.com>
 <f671a112-880d-1526-a395-360947b40c5a@gmx.de> <YfEv7OQs98O9wJdJ@kroah.com>
 <YfFIpBb7lL4ukWjm@smile.fi.intel.com>
 <b8eb7111-43aa-cc8a-a1bc-f08e0f2987ed@redhat.com>
 <YfFV4EJosayH+e6C@smile.fi.intel.com> <YfFWPmG2D093gz4N@smile.fi.intel.com>
 <6e74d4cc-655a-e38e-0856-a59e4e6deb36@redhat.com>
 <c423a2f0-e7be-3884-3568-7629c7e9104e@redhat.com>
 <ddb0f354-be19-92fe-20b3-56b00c9304ab@suse.de>
From:   Javier Martinez Canillas <javierm@redhat.com>
In-Reply-To: <ddb0f354-be19-92fe-20b3-56b00c9304ab@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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