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]

Message-ID: <9814d071-2a01-f452-8bf9-4d216a11186d@gmx.de>
Date:   Mon, 17 Jan 2022 12:33:34 +0100
From:   Helge Deller <deller@....de>
To:     Thomas Zimmermann <tzimmermann@...e.de>,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Hi Thomas,

On 1/17/22 12:16, Thomas Zimmermann wrote:
> Hi
>
> Am 14.01.22 um 19:11 schrieb Helge Deller:
>> The fbdev layer is orphaned, but seems to need some care.
>> So I'd like to step up as new maintainer.
>>
>> Signed-off-by: Helge Deller <deller@....de>
>
> First of all, thank you for stepping up to maintain the fbdev
> codebase. It really needs someone actively looking after it.

Thanks.

> And now comes the BUT.
>
> I want to second everything said by Danial and Javier. In addition to
> purely organizational topics (trees, PRs, etc), there are a number of
> inherit problems with fbdev.

I will answer that in the other mail to Daniel shortly...

> * It's 90s technology. Neither does it fit today's userspace, not
> hardware. If you have more than just the most trivial of graphical
> output fbdev isn't for you.

Right.
I'm working and maintaining such hardware.
There is not just x86, there is not just Intel/AMD/nvidia graphics
and for those fbdev is still (and will be) important.

> * There's no new development in fbdev and there are no new drivers.
> Everyone works on DRM, which is better in most regards.

In most regards yes.
So, don't get me wrong.
I fully agree DRM that is the way forward.
But on the way forward we shouldn't try to actively break code for others.

> The consequence is that userspace is slowly loosing the ability to
> use fbdev.
Maybe.

> * A few use-cases for efifb remain, but distributions are actively
> moving away from fbdev. I know that at least openSUSE, Fedora and
> Alpine do this.

Debian is still running on lots of hardware, either which isn't x86 or
which is old hardware.
The distributions you mentioned still need fbdev for machines were DRM isn't
available (yet).

> I'd like to hear what your plans are for fbdev?

That's easy:
* To maintain it.
* To keep it working for where DRM can't be used.
* My goal is NOT to work against DRM. That's the future of course.

Helge

>
> Best regards
> Thomas
>
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d0cd537803a..ce47dbc467cc 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7583,11 +7583,12 @@ W:    http://floatingpoint.sourceforge.net/emulator/index.html
>>   F:    arch/x86/math-emu/
>>
>>   FRAMEBUFFER LAYER
>> -L:    dri-devel@...ts.freedesktop.org
>> +M:    Helge Deller <deller@....de>
>>   L:    linux-fbdev@...r.kernel.org
>> -S:    Orphan
>> +L:    dri-devel@...ts.freedesktop.org
>> +S:    Maintained
>>   Q:    http://patchwork.kernel.org/project/linux-fbdev/list/
>> -T:    git git://anongit.freedesktop.org/drm/drm-misc
>> +T:    git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>>   F:    Documentation/fb/
>>   F:    drivers/video/
>>   F:    include/linux/fb.h
>