Re: [PATCH v2 1/3] auxdisplay: Take over maintainership, but in Odd Fixes mode

[Andy Shevchenko]

On Tue, Feb 13, 2024 at 09:10:48AM +0100, Javier Martinez Canillas wrote:
> Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> 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