[PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Thomas Zimmermann tzimmermann at suse.de
Mon Jan 17 12:13:14 UTC 2022


Hi

Am 17.01.22 um 12:33 schrieb Helge Deller:
> 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 at gmx.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.

We don't actively break fbdev for anyone. Actually, after ~20yrs we 
finally added testcases for fbdev ioctls, so that we avoid regressions.

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

There might be outliers, but I don't think the Linux desktops support 
fbdev in Wayland mode. For Weston, the last thing I heard was that fbdev 
is supposed to be dropped in one of the next releases.

Fbdev is mostly handled by old Xorg or maybe whatever embedded vendors 
implement. Note the DRM drivers still support fbdev interfaces via 
/dev/fb* for legacy userspace.

> 
>> * 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).

Not really. From [1], Alpine apparently switched already. openSUSE [2] 
and Fedora [3] are in the process of doing so. Debian can easily follow.

We now do have the ability to run DRM from early stages of the boot 
process without the need for fbdev. What we still use is the fbcon 
console. There are ideas to replace that as well.

> 
>> 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.
> 

IMHO that second bullet really misses the point. DRM can be used where 
ever fbdev is still required. The only thing stopping it is the 
availability of a hardware driver.

A meaning contribution would be to port fbdev drivers over to DRM. That 
makes modern features available on that hardware in both, kernel and 
userspace. We do take drivers for old hardware. I even made 
fbdev-conversion helpers a while ago. [4]

If you can point to graphics hardware that should have a DRM driver, 
I'll help any volunteers with the conversion.

But keeping fbdev alive for such hardware only contributes to the 
fragmentation and makes these systems even more obsolete.

Best regards
Thomas

[1] https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.15
[2] https://bugzilla.opensuse.org/show_bug.cgi?id=1193250
[3] https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers
[4] 
https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/fbconv-plus-drivers

> 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 at lists.freedesktop.org
>>> +M:    Helge Deller <deller at gmx.de>
>>>    L:    linux-fbdev at vger.kernel.org
>>> -S:    Orphan
>>> +L:    dri-devel at lists.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
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220117/7f22dd71/attachment.sig>


More information about the dri-devel mailing list