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

[Javier Martinez Canillas <javierm@redhat.com>]

Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:

Hello Andy,

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

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

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

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

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat