Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <c80ed72c-2eb4-16dd-a7ad-57e9dde59ba1@gmx.de>
Date:   Mon, 17 Jan 2022 13:15:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Content-Language: en-US
To:     Daniel Vetter <daniel@ffwll.ch>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "airlied@gmail.com" <airlied@gmail.com>
Cc:     linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
        linux-kernel@vger.kernel.org,
        Javier Martinez Canillas <javierm@redhat.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>
References: <YeG8ydoJNWWkGrTb@ls3530>
 <CAKMK7uGdJckdM+fg+576iJXsqzCOUg20etPBMwRLB9U7GcG01Q@mail.gmail.com>
From:   Helge Deller <deller@gmx.de>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
In-Reply-To: <CAKMK7uGdJckdM+fg+576iJXsqzCOUg20etPBMwRLB9U7GcG01Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hello Daniel,

On 1/17/22 11:02, Daniel Vetter wrote:
> Hi Helge
>
> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>
>> The fbdev layer is orphaned, but seems to need some care.
>> So I'd like to step up as new maintainer.
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d0cd537803a..ce47dbc467cc 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/em=
ulator/index.html
>>  F:     arch/x86/math-emu/
>>
>>  FRAMEBUFFER LAYER
>> -L:     dri-devel@lists.freedesktop.org
>> +M:     Helge Deller <deller@gmx.de>
>>  L:     linux-fbdev@vger.kernel.org
>> -S:     Orphan
>
> Maybe don't rush maintainer changes in over the w/e without even botheri=
ng
> to get any input from the people who've been maintaining it before.
>
> Because the status isn't entirely correct, fbdev core code and fbcon and
> all that has been maintained, but in bugfixes only mode. And there's ver=
y
> solid&important reasons to keep merging these patches through a drm tree=
,
> because that's where all the driver development happens, and hence also
> all the testing (e.g. the drm test suite has some fbdev tests - the only
> automated ones that exist to my knowledge - and we run them in CI). So
> moving that into an obscure new tree which isn't even in linux-next yet =
is
> no good at all.
>
> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> welcome anyone stepping up for that, but the simplest approach there wou=
ld
> be to just get drm-misc commit rights and push the oddball bugfix in the=
re
> directly. But also if you want to do your own pull requests to Linus for
> that I don't care and there's really no interference I think, so
> whatever floats.
>
> But any code that is relevant for drm drivers really needs to go in thro=
ugh
> drm trees, nothing else makes much sense.
>
> I guess you're first action as newly minted fbdev maintainer is going to=
 be to
> clean up the confusion you just created.

Most of my machines depend on a working fbdev layer since drm isn't (and p=
robably
-due to technical requirements of DRM- won't be) available for those.
So, since the fbdev drivers were marked orphaned, I decided to step up as =
maintainer.

I see your point that at least the fbdev core code and fbcon are shared be=
tween DRM and fbdev.
For me it's really not important to drive any patches through a seperate t=
ree, so
I'd be happy to join the drm-misc tree if you feel it's necessary. (By the=
 way,
adding my tree to for-next was on my todo list...)

What's important for me though is, to keep fbdev actively maintained, whic=
h means:
a) to get fixes which were posted to fbdev mailing list applied if they ar=
e useful & correct,
b) to include new drivers (for old hardware) if they arrive (probably happ=
ens rarely but there can be).
   I know of at least one driver which won't be able to support DRM....
   Of course, if the hardware is capable to support DRM, it should be writ=
ten for DRM and not applied for fbdev.
c) reintroduce the state where fbcon is fast on fbdev. This is important f=
or non-DRM machines,
   either when run on native hardware or in an emulator.
d) not break DRM development

Especially regarding c) I complained in [1] and got no feedback. I really =
would like to
understand where the actual problems were and what's necessary to fix them=
.

Helge

[1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de