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]

Date:   Mon, 24 Jan 2022 19:50:37 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Gerd Hoffmann <kraxel@...hat.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        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 Mon, Jan 24, 2022 at 7:39 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@...ll.ch> wrote:
> > 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).
>
> I doubt that RGB332 would be a bit more work than C4, as RGB332 is still
> 8 bpp, while C4 is less.  To support C4, all DRM code that cannot
> handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be
> fixed first.

Hm what's broken with it? Current code means it cannot support odd
width for C4 (because to make C4 fit into bytes you need 2 pixels),
but otherwise this should all work. Iirc we have formats with "5
pixels in 4 bytes" and fun stuff like that. Note that stride and also
the actual window you scan out are all separate, so even if your hw
needs an odd stride or you have an odd resolution it should still all
work out for C4 with the existing infra.

RGB322 is more work because in the fbdev code this aliases with bpp=8
which is C8, because no one has yet moved the fbdev emulation code
forward into the drm_fourcc world.

> On the plus side, I finally got my proof-of-concept Atari DRM driver
> working with fbcon on ARAnyM.  Mapping /dev/fb0 from userspace doesn't
> work (fbtest SEGVs while reading from the mapped frame buffer).  I don't
> know yet if this is a general issue without deferred I/O in v5.17-rc1,
> or a bug in the m68k MM code...
>
> So far it supports C8 only, but I hope to tackle C4 and monochrome soon.
> Whether the end result will be usable on real hardware is still to be
> seen, but at least I hope to get some DRM code written...

Yay, this sounds interesting!
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch