linux-kernel - Re: [RFC PATCH 0/3] staging: remove fbdev drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANq1E4S51c-fwJMN2P9MnhuErANvwfy41W2WBSSXrFPS3DXPkg@mail.gmail.com>
Date:   Fri, 9 Dec 2016 14:57:24 +0100
From:   David Herrmann <dh.herrmann@...il.com>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Noralf Trønnes <noralf@...nnes.org>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Teddy Wang <teddy.wang@...iconmotion.com>,
        Arnaud Patard <arnaud.patard@...-net.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers

Hey

On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter <daniel@...ll.ch> wrote:
>> > So it is possible, only reason vram dumb buffers look worse is that there's
>> > only 3 and no one cares about them, vs about 20 and a very active community
>> > of contributors (also for core drm improvements) for the other case.
>>
>> Well, we could move offb to drm while at it I suppose that would be another
>> one (offb is the "dumb driver based on pre-programmed output by firmware).
>
> One of the still in-flight drm drivers is the simpledrm thing meant for
> all kinds of firmware drivers like efifb and similar things on arm for
> pre-programmed output set up by firmware. I.e. no modeset support and
> otherwise a lot of fake to make it work as drm driver, but the idea that
> it's good enough until your real drm driver takes over.

The x86 platform device fixups for SimpleDRM went in some weeks ago,
so maybe I should resend the patches. The driver could easily do
'offb'-like devices as well. Trivial to add.

Anyway, Benjamin is right, we always do shadow buffering for trivial
drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
dirty-ioctl. Reason is that we cannot easily expose the real
framebuffer in DRM via FB-objects. But I also never saw a use-case for
it, since all trivial devices I worked with were only either used as
fallback or nobody cared for performance.

The generic DRM API is designed for dynamic FB allocation. If your
hardware does not allow you to change the scanout source, you will
have a hard time trying to expose the static buffers via the dynamic
FB-object API. Furthermore, all DRM user-space expects dynamic FB
management to work, preferably without a ridiculously low memory
limit. That's also why I never bothered changing the drivers.

Despite all of this I still see no reason why a driver could not
expose the static, real frambuffers via private ioctls. You can get
all your fancy acceleration that way. Then fix user-space to use this
API. If enough drivers end up with something similar, move it into the
core. Just like we always do in DRM.

Thanks
David