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;
From:   Sven Schnelle <svens@linux.ibm.com>
To:     Helge Deller <deller@gmx.de>
Cc:     Daniel Vetter <daniel@ffwll.ch>,
        Javier Martinez Canillas <javierm@redhat.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Andy Shevchenko <andy@kernel.org>, linux-fbdev@vger.kernel.org,
        Michael Hennerich <michael.hennerich@analog.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org,
        Phillip Potter <phil@philpotter.co.uk>,
        Carlis <zhangxuezhi1@yulong.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Lee Jones <lee.jones@linaro.org>,
        Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance
References: <20220125202118.63362-1-andriy.shevchenko@linux.intel.com>
        <991e988b-7225-881b-a59a-33c3eae044be@suse.de>
        <CAHp75Vc2cjHkJwNSiJ-HSWBG=DYy68uvD7QQzNdRp3mQxoY1nw@mail.gmail.com>
        <3877516e-3db3-f732-b44f-7fe12b175226@gmx.de>
        <b13c0634-e766-74db-ab1f-672f5d0c04d6@redhat.com>
        <CAKMK7uEqwyZuVheqyNG33Un4WK1cd1B+WBYbCmi20fZi0qVG2w@mail.gmail.com>
        <88ea01b8-3fdd-72cc-c3d8-e2890c68533b@gmx.de>
Date:   Wed, 26 Jan 2022 12:45:23 +0100
In-Reply-To: <88ea01b8-3fdd-72cc-c3d8-e2890c68533b@gmx.de> (Helge Deller's
        message of "Wed, 26 Jan 2022 12:38:09 +0100")
Message-ID: <yt9d35lara98.fsf@linux.ibm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Helge Deller <deller@gmx.de> writes:

> On 1/26/22 12:24, Daniel Vetter wrote:
>> And that point was about 5 years ago, and has been discussed at some
>> plumbers meanwhile, resulting in the staging TODO patches to make
>> these drm drivers to destage them.
>>
>> Fixing bugs in fbdev is all fine, reopening it for merging new drivers is not.
>
> We are on the same page!
> I'm not at all proposing to include new drivers for (relatively) new
> hardware into fbdev, which is capable to be written as DRM driver.

In my opinion that should be decided depending on the main usecase: If
it's X11 or similar, it should go to DRM. If its main use case is kernel
text console, it should go to fbdev.

I think the main concern/trouble about fbdev is the userspace interface,
and i personally would be totally fine seeing that go away (except the
ability to change video mode with fbset). For me its important as kernel
console for old systems, and don't want to run X11 on them.

Given the ongoing discussion about performance and drm, i don't expect
DRM gaining HW acceleration capabilities for text consoles. So i think
both should exist, just for different usecases.