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

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

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 MAINTAINERS | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
  

On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
> (cc'ing Javier Martinez Canillas)
> 
> Hi
> 
> 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...
> 
> 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).
  

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

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

On Mon, Feb 12, 2024 at 2:27 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> 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...

Thanks Andy, I appreciate it:

Acked-by: Miguel Ojeda <ojeda@kernel.org>

if you want to already take it yourself :)

Otherwise I can pick it up.

Cheers,
Miguel
  

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

Hi

Am 12.02.24 um 17:42 schrieb Andy Shevchenko:
> On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
>> (cc'ing Javier Martinez Canillas)
>>
>> Hi
>>
>> 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...
>> 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).

I see. Taking a closer look, it's not as simple as I implied.

We noticed that cfag1286bfb and ht16k33 are fbdev-based drivers. They 
seem to belong into video/fbdev. But OTOH ht16k33 appears to drive 
14-segment displays and fbdev appears to be an odd choice for such 
devices. And as Javier already noted, we wondered if these charlcd 
displays aren't just a special case of TTYs.

Best regards
Thomas

>
  

Hi Thomas,

On Tue, Feb 13, 2024 at 9:28 AM Thomas Zimmermann <tzimmermann@susede> wrote:
> Am 12.02.24 um 17:42 schrieb Andy Shevchenko:
> > On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
> >> (cc'ing Javier Martinez Canillas)
> >> 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...
> >> 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).
>
> I see. Taking a closer look, it's not as simple as I implied.
>
> We noticed that cfag1286bfb and ht16k33 are fbdev-based drivers. They
> seem to belong into video/fbdev. But OTOH ht16k33 appears to drive
> 14-segment displays and fbdev appears to be an odd choice for such
> devices. And as Javier already noted, we wondered if these charlcd
> displays aren't just a special case of TTYs.

HT16K33 uses line-display for 7/14-segment displays, and fbdev
for dot-matrix displays. And input for the optional keypad.

I started working on splitting the functionality, at least
CONFIG_*-wise, so you can still build it for line-display with
CONFIG_FB=n, but I was distracted by more important work...

Gr{oetje,eeting}s,

                        Geert
  

On Tue, Feb 13, 2024 at 9:10 AM Javier Martinez Canillas
<javierm@redhat.com> wrote:
>
> 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).

Thanks Javier, I appreciate the kind words.

To clarify, auxdisplay has had just about 16 patches a year (i.e. very
low), and a significant fraction of those came from Andy and Geert. In
addition, they have some of the relevant hardware and have tested
patches in the past (which I really appreciated). By contrast, I have
not had any of the hardware for years now.

So I asked Geert and Andy in private if they wanted to become the
maintainers/reviewers. They do not have much time, but Andy wants to
submit a new driver anyway, so we ended up going with Andy as M and
Geert as R, which I really appreciate.

If somebody else wants to join, I am sure they would be happy to. And
for those that may not be involved with upstream development but have
some kernel development experience, this may be a nice opportunity as
well to try becoming a reviewer/maintainer -- it is a small, fun
subsystem (if you have the hardware), with low traffic, and with a few
experienced maintainers around it like Andy and Geert that may be able
to help test patches etc.

Cheers,
Miguel
  

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.