On 1/18/22 09:41, Helge Deller wrote: > Hello Daniel, > > On 1/17/22 16:00, Daniel Vetter wrote: >> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@xxxxxx> wrote: >>> On 1/17/22 11:02, Daniel Vetter wrote: >>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@xxxxxx> 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@xxxxxx> >>>>> >>>>> 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@xxxxxxxxxxxxxxxxxxxxx >>>>> +M: Helge Deller <deller@xxxxxx> >>>>> L: linux-fbdev@xxxxxxxxxxxxxxx >>>>> -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). To make it more clear: I'm not planning to push code to fbdev/fbcon without having discussed everything on dri-devel. Everything which somehow would affect DRM needs to be discussed on dri-devel and then - after agreement - either pushed via the fbdev git tree or the drm-misc tree. Helge > 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@xxxxxx >> >> >> >