Date:   Tue, 18 Jan 2022 09:41:50 +0100
From:   Helge Deller <deller@....de>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "airlied@...il.com" <airlied@...il.com>,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org,
        Javier Martinez Canillas <javierm@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Hello Daniel,

On 1/17/22 16:00, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@....de> wrote:
>> On 1/17/22 11:02, Daniel Vetter wrote:
>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@....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@....de>
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 5d0cd537803a..ce47dbc467cc 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>>  F:     arch/x86/math-emu/
>>>>
>>>>  FRAMEBUFFER LAYER
>>>> -L:     dri-devel@...ts.freedesktop.org
>>>> +M:     Helge Deller <deller@....de>
>>>>  L:     linux-fbdev@...r.kernel.org
>>>> -S:     Orphan
>>>
>>> Maybe don't rush maintainer changes in over the w/e without even bothering
>>> 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 very
>>> 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 would
>>> be to just get drm-misc commit rights and push the oddball bugfix in there
>>> 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 through
>>> 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 probably
>> -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 between DRM and fbdev.
>> For me it's really not important to drive any patches through a seperate tree, 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, which means:
>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
>
> Yeah it'd be great if we have that, for a while Bart took care of
> these, but had to step down again. drm-misc is maintained with the dim
> scrip suite, which comes with docs and bash completion and everything.
> Good starting pointer is here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>
> Process for getting commit rights is documented here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
>
> But there's a pile more. I think once we've set that up and got it
> going we can look at the bigger items. Some of them are fairly
> low-hanging fruit, but the past 5+ years absolutely no one bothered to
> step up and sort them out. Other problem areas in fbdev are extremely
> hard to fix properly, without only doing minimal security-fixes only
> support, so fair warning there. I think a good starting point would be
> to read the patches and discussions for some of the things you've
> reverted in your tree.
>
> Anyway I hope this gets you started, and hopefully after a minor
> detour: Welcome to dri-devel, we're happy to take any help we can get,
> there's lots to do!

Thanks for this info, Daniel!

After reading those docs I've decided not to join dri-devel and keep
my existing linux-fbdev tree at:

https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git

The linux-fbdev is a low-volume mailing list with mostly small bug fixes
or enhancements for the fbdev drivers. Those patches usually don't affect DRM.

I'm expecting that non-trivial changes which may affect fbdev will be sent to the
linux-fbdev mailing list, same way as I will of course send any patches which
might affect DRM to dri-devel.

My git tree is wired up to the for-next pull chain, so in any way we would notice
merge conflicts (which I believe will not happen).

Cheers,

Helge

>> b) to include new drivers (for old hardware) if they arrive (probably happens 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 written for DRM and not applied for fbdev.
>> c) reintroduce the state where fbcon is fast on fbdev. This is important for 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
>
>
>

Powered by blists - more mailing lists