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: <CAMuHMdW=Zpp2mHbrBx7i0WN8PqY3XpK5qpyAyYxgf9n88edpug@mail.gmail.com>
Date:   Mon, 17 Jan 2022 14:29:47 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Gerd Hoffmann <kraxel@...hat.com>
Cc:     Helge Deller <deller@....de>, Daniel Vetter <daniel@...ll.ch>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "airlied@...il.com" <airlied@...il.com>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Javier Martinez Canillas <javierm@...hat.com>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Hi Gerd,

On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@...hat.com> wrote:
> > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >    I know of at least one driver which won't be able to support DRM....
>
> Hmm?  I seriously doubt that.  There is always the option to use a
> shadow framebuffer, then convert from standard drm formats to whatever
> esoteric pixel format your hardware expects.
>
> Been there, done that.  Have a look at the cirrus driver.  The physical
> hardware was designed in the early 90-ies, almost 30 years ago.  These
> days it exists in virtual form only (qemu emulates it).  Thanks to the
> drm driver it runs wayland just fine even though it has a bunch of
> constrains dictated by the hardware design.

The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
modes only.  The Cirrus fbdev driver also supports mochrome and 256
color modes.

There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
frame buffer to convert from truecolor to 256 colors would be doable,
but would give bad results. And what about less colors?
Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
the DRM core assumes in many places that a pixel is at least 1 byte,
and would crash otherwise (yes I tried).  Other modes needed are
DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
This not only to support "old" hardware, but also modern small OLED
and e-ink displays.

On the positive side: DRM would force e.g. the Amiga and Atari
bitplane formats to become internal to the kernel driver, with the
kernel driver converting from packed pixels to bitplanes.  Hence
userspace would no longer have to care about bitplanes.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds