Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <1400f204-9dd0-585b-d58f-be98977d40b4@gmx.de>
Date:   Tue, 18 Jan 2022 12:42:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Content-Language: en-US
To:     Daniel Vetter <daniel@ffwll.ch>
Cc:     Jani Nikula <jani.nikula@linux.intel.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        linux-fbdev@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        Javier Martinez Canillas <javierm@redhat.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>
References: <YeG8ydoJNWWkGrTb@ls3530>
 <CAKMK7uGdJckdM+fg+576iJXsqzCOUg20etPBMwRLB9U7GcG01Q@mail.gmail.com>
 <c80ed72c-2eb4-16dd-a7ad-57e9dde59ba1@gmx.de>
 <CAKMK7uHVHn9apB6YYbLSwu+adEB2Fqp4FM0z582zf4F-v3_GnQ@mail.gmail.com>
 <cf21018b-f231-7538-169e-2ad450643cbf@gmx.de>
 <97d49bca-f5f7-dba4-b62d-b6fcdd4276ac@suse.de> <87ee5659dt.fsf@intel.com>
 <4f1d6018-d74e-8e62-ea4d-0ca79c6bbbc5@gmx.de> <87a6ft5thv.fsf@intel.com>
 <5ba33e10-7d75-9f9a-dfd6-c04608d230a4@gmx.de>
 <CAKMK7uG48Due9Tv_78BJT52hvC5JcbT6-7S6_Qt7FiZ-GrTRzw@mail.gmail.com>
From:   Helge Deller <deller@gmx.de>
In-Reply-To: <CAKMK7uG48Due9Tv_78BJT52hvC5JcbT6-7S6_Qt7FiZ-GrTRzw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

	On 1/18/22 12:18, Daniel Vetter wrote:
> On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/18/22 09:38, Jani Nikula wrote:
>>> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
>>>> On 1/17/22 22:40, Jani Nikula wrote:
>>>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.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-d=
evel
>>>>> also?
>>>>
>>>> Doesn't seem like much traffic - which IMHO is OK for such a tree wit=
h
>>>> 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 i=
n the SCROLL_REDRAW case.
In addition there are some fbdev drivers which provide 2D support and inst=
ead 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 suppo=
rted.

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 nee=
d
>>> to be sent to dri-devel.
>>
>> Helge
>
>
>