Hi Javier, On Tue, Jan 18, 2022 at 10:33 AM Javier Martinez Canillas <javierm@xxxxxxxxxx> wrote: > On 1/18/22 09:54, Helge Deller wrote: > > On 1/18/22 09:38, Jani Nikula wrote: > >> On Mon, 17 Jan 2022, Helge Deller <deller@xxxxxx> wrote: > >>> On 1/17/22 22:40, Jani Nikula wrote: > >>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > >>>>> Seems like few people read linux-fbdev these days. > >>>> > >>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > >>>> also? > >>> > >>> Doesn't seem like much traffic - which IMHO is OK for such a tree with > >>> mostly just maintenance patches. > >>> > >>>> Do we still need a separate linux-fbdev mailing list at all? > >>> > >>> Yes. I want to have it seperate of dri-devel. > >>> Actually I'd prefer to drop dri-devel from the list where patches > >>> for fbdev are sent... > >> > >> Disagreed. If anything, this thread shows we can't have fbdev and drm in > >> silos of their own. > > > > Patches to fbdev usually don't affect DRM. > > Patches for fbdev drivers don't usually affect DRM but that's not the > case for patches to fbdev core and fbcon as you and others mentioned. > > > Patches which affect DRM needs to through to dri-devel. > > And how would people know which ones need to go through dri-devel ? Are > you planning to add another entry to MAINTAINERS for fbdev core/fbcon ? Those are nicely contained in drivers/video/fbdev/core/, so an entry in MAINTAINERS listing both linux-fbdev and dri-devel would do. > > In addition this would take the burden of the dri-developers to receive > > unrelated fbdev driver updates and patches. > > In my opinion having fbdev patches in the dri-devel mailing list isn't > a big burden, but rather getting people to review and push say patches. > > Since you are volunteering for the latter, that should improve things. > > I still fail to see the benefit of doing that split, same for having a > separate fbdev tree. Using drm-misc only have advantages, among other > things providing redundancy in cases that a maintainer isn't available > for a period of time. The above is the point of view from a DRM developer? For an fbdev developer, the burden to receive unrelated DRM driver updates and patches would be significant. The first page of https://lore.kernel.org/dri-devel/ goes back to yesterday. The first page of https://lore.kernel.org/linux-fbdev/ goes back to Nov 30th. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
