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: <CAKMK7uF-V20qWTxQLvTC6GjC8Sg+Pst+UJ3pWCLQ4Q7Khgy62g@mail.gmail.com>
Date:   Fri, 21 Jan 2022 09:55:25 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Gerd Hoffmann <kraxel@...hat.com>
Cc:     Thomas Zimmermann <tzimmermann@...e.de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Helge Deller <deller@....de>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        Sven Schnelle <svens@...ckframe.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

On Fri, Jan 21, 2022 at 9:46 AM Gerd Hoffmann <kraxel@...hat.com> wrote:
>
>   Hi,
>
> > What I still don't understand: why are you so keen on maintaining an
> > interface that only serves the console? Nothing else uses fbdev these days.
> > Why not improve DRM/userspace to the point where it fits your requirements?
> > Long-term, the latter would make a lot more sense.
>
> And note that it is *much* easier to write drm drivers these days.
> We got alot of helpers, we got generic fbdev emulation and more.
>
> If you are curious just compare the initial commit of the bochs drm
> driver with the current code.  Initially the driver had to manage ttm
> and fbdev and whatnot else.  These days writing a (non-accelerated) drm
> driver is basically some boilerplate picking the helpers which work best
> for your hardware, the code to actually program the hardware and that's
> it.
>
> The "new drivers should be drm" policy exists for years already btw,
> exactly because of the unfixable fbdev API limitations.  The bochs drm
> was a fbdev driver initially.  Never merged.  Got rewritten as drm
> driver and that was merged instead.  In 2013, almost a decade ago.
>
> And, yes, it very well might be that drm misses some piece here and
> there for specific hardware, such as fbdev emulation not supporting
> rgb332.  But I fully agree with Thomas here:  Improving drm is probably
> a much better way to spend your time.  drm is where the development
> happens.  fbdev is only kept alive.

Just to clarify, since we had lots of smaller and bigger
misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so
drm support that already. The fbdev emulation doesn't yet, but all
that's needed for that is filling out the code to remap the drm
description to the fbdev format description for this case. Plus
testing it all works ofc with fbcon and whatelse. Note that RGB332  is
a bit more work than e.g. C4, since atm fbdev still uses only bpp to
identify formats, so would need to be switch over to drm_fourcc first
before adding anything which aliases with something existing (we have
C8 already wired up).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch