linux-kernel - Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jan 2022 12:18:31 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Helge Deller <deller@....de>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        linux-fbdev@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Javier Martinez Canillas <javierm@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@....de> wrote:
>
> On 1/18/22 09:38, Jani Nikula wrote:
> > On Mon, 17 Jan 2022, Helge Deller <deller@....de> wrote:
> >> On 1/17/22 22:40, Jani Nikula wrote:
> >>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@...e.de> 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