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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sf1wkcmv.fsf@minerva.mail-host-address-is-not-set>
Date: Tue, 13 Feb 2024 09:10:48 +0100
From: Javier Martinez Canillas <javierm@...hat.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Thomas Zimmermann
 <tzimmermann@...e.de>
Cc: linux-kernel@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>, Geert
 Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH v2 1/3] auxdisplay: Take over maintainership, but in Odd
 Fixes mode

Andy Shevchenko <andriy.shevchenko@...ux.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