On 1/18/22 12:18, Daniel Vetter wrote: > 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'm fine with keeping both lists mentioned in the MAINTAINERS file. It was a proposal and I understand you want to keep it. Ok for me. > 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. I don't see *any impact* on drm drivers at all if both patches would be reverted now. > 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. I wonder why you don't want to give it a try? My current proposal is to revert those two changes. Reverting them does not affect DRM code. Both DRM and some fbdev drivers still share excactly the same code paths in the SCROLL_REDRAW case. In addition there are some fbdev drivers which provide 2D support and instead allow SCROLL_MOVE. That's it. Currently I don't know which other cleanups or refactorings of fbcon are planned from DRM side, but I'm sure there is a easy way to keep both supported. If it then really turns out that it's not possible we can decide then how to continue. Helge > -Daniel > >>> Also, if the patches continue to get merged through drm-misc, they need >>> to be sent to dri-devel. >> >> Helge > > >
