Received-SPF: pass (google.com: domain of linux-kernel+bounces-63731-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 13 Feb 2024 16:55:26 +0200
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>, linux-kernel@vger.kernel.org,
	Miguel Ojeda <ojeda@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v2 1/3] auxdisplay: Take over maintainership, but in Odd
 Fixes mode
Message-ID: <ZcuC3jGSVI4MqDeN@smile.fi.intel.com>
References: <20240212132515.2660837-2-andriy.shevchenko@linux.intel.com>
 <20240212132515.2660837-3-andriy.shevchenko@linux.intel.com>
 <9c7df0e5-31a9-4c86-b996-4cba82c4ea2f@suse.de>
 <ZcpKh_EgNM5IaV-P@smile.fi.intel.com>
 <ZcpKwz8J8OoODMYl@smile.fi.intel.com>
 <87sf1wkcmv.fsf@minerva.mail-host-address-is-not-set>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87sf1wkcmv.fsf@minerva.mail-host-address-is-not-set>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Tue, Feb 13, 2024 at 09:10:48AM +0100, Javier Martinez Canillas wrote:
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> > On Mon, Feb 12, 2024 at 06:42:48PM +0200, Andy Shevchenko wrote:
> >> On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
> >> > Am 12.02.24 um 14:23 schrieb Andy Shevchenko:

..

> >> > > I have no time for this, but since it looks like I'm the main
> >> > > contributor for the last few years to the subsystem, I'll take
> >> > > it for now. Geert agreed to help me with as a designated reviwer.
> >> > > Let's see how it will go...
> 
> AFAICT Miguel Ojeda is quite responsive and is still doing reviews/acks
> for auxdisplay patches. Can you elaborate why the maintainership change
> has to be made?
> 
> You can still be listed as co-maintainer of course, and maybe Miguel is
> on board to drop this but then I think that should be mentioned in your
> commit message (and have an ack from him).

He answered you in a separate email. I have nothing to add.

..

> >> > A few days ago, I talked to Javier about how auxdisplay is a hotchpodge of
> >> > various drivers that seem to belong into other subsystems. Could we attempt
> >> > to move all drivers into other places and then remove the auxdisplay
> >> > subsystem?
> >> 
> >> Can you be more precise on how it can be done? We have at least two clusters of
> >> the displays: line-display and HD44780-based ones. Moreover, the latter might
> >> use the former in the future (in some cases).
> 
> For line-display and 7-segment display I'm less sure, and it may be that
> we do need a specific subsystem for those. But then maybe it has to be
> renamed to text-based or character based displays instead ?

"text" is incorrect term here, as 7-segment LEDs can only emulate text to some
extent. Poorly TBH. HD44780 can hold the overrides for the font, which makes
it not so text either (yes, the old xGA [x = C,E,V,...] display controllers
already can do the same in some text modes).

> I wonder though if these can be modeled as an output only tty instead.
> 
> There are though more than these two types of display, for example the
> cfag12864bfb driver is a FB_VISUAL_MONO10 fbdev driver:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/auxdisplay/cfag12864bfb.c
> 
> Now that we have better support in DRM/KMS for monochrome displays, it
> seems to me that could be even ported and be a modesetting driver. I've
> mentioned this to a colleague who wants to get start with Linux graphics
> as a good learning exercise.

I believe you are too much focused on the _exceptional_ drivers, most of which
are _not_ FB ones.

> I believe the problem is that auxdisplay is too vague of a term, so anything
> could be an "auxdisplay". Even tiny I2C/SPI panels could be defined as that.

I understand the term well, SPI/I2C display, when it's the main one can't be
aux. The latter one, e.g., is an LCD on the server panel, or 7-segment LEDs
on the motherboard for debug.

Definitely, as a maintainer, I would not accept the driver that belongs to
FB/DRM if it's clear that it has no tights to the 7-seg/N-seg / line or its
main usage is display panels.

> > Btw, I have no time for major things here, if you wish, please take over,
> > I will be happy to get rid of this.

-- 
With Best Regards,
Andy Shevchenko