On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@xxxxxx> 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 which affect DRM needs to through to dri-devel. > In addition this would take the burden of the dri-developers to receive > unrelated fbdev driver updates and patches. I added dri-devel for fbdev because stuff landed that shouldn't have. Let's not remove that, because the amount of patches for fbdev which arent relevant for drm drivers is pretty much nothing. I really don't like the idea that fbdev goes off again becoming a silo, just because it's too hard to wire through low-bit greyscale support. Which no I can't type for you, because I don't have such hw here. Everything where people cared enough for adding fbdev compat support for to actually write a patch is supported. If you do want a silo for fbdev then I think the only reasonable option is that we create a copy of the fbdev/fbcon code for drm (somewhat renamed), so that you can do the reverts without impacting drm drivers. But there will still be some overlap and minimal coordination, plus I'm not seeing anyone from the drm side volunteering for the sizeable amount of work. -Daniel > > Also, if the patches continue to get merged through drm-misc, they need > > to be sent to dri-devel. > > Helge -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
