On 1/17/22 16:00, Daniel Vetter wrote:

On Mon, Jan 17, 2022 at 1:16 PM Helge Deller [off-list ref] wrote:

quoted

Hello Daniel,

On 1/17/22 11:02, Daniel Vetter wrote:

quoted

Hi Helge

On Fri, Jan 14, 2022 at 7:18 PM Helge Deller [off-list ref] wrote:

quoted

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/emulator/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 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!

Hello Daniel,

you somehow missed to answer my main topics below...:

quoted

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 (local)