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: <a922343d-8805-3446-c000-cf7969699823@mailbox.org>
Date:   Tue, 18 Jan 2022 09:58:13 +0100
From:   Michel Dänzer <michel.daenzer@...lbox.org>
To:     Sven Schnelle <svens@...ckframe.org>,
        Thomas Zimmermann <tzimmermann@...e.de>
Cc:     Helge Deller <deller@....de>, linux-fbdev@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

On 2022-01-17 19:47, Sven Schnelle wrote:
> 
>>  * There's no new development in fbdev and there are no new
>>    drivers. Everyone works on DRM, which is better in most
>>    regards. The consequence is that userspace is slowly loosing the
>>   ability to use fbdev.
> 
> That might be caused by the fact that no new drivers are accepted for
> fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last
> year which was rejected for inclusion into fbdev[1].
> 
> Based on your recommendation i re-wrote the whole thing in DRM. This
> works but has several drawbacks:
> 
> - no modesetting. With fbdev, i can nicely switch resolutions with
>   fbset. That doesn't work, and i've been told that this is not supported[2]
> 
> - It is *much* slower than fbset with hardware blitting. I would have to
>   dig out the numbers, but it's in the ratio of 1:15. The nice thing
>   with fbdev blitting is that i get an array of pixels and the
>   foreground/background colors all of these these pixels should have.
>   With the help of the hardware blitting, i can write 32 pixels at once
>   with every 32-bit transfer.
> 
>   With DRM, the closest i could find was DRM_FORMAT_C8, which means one
>   byte per pixel. So i can put 4 pixels into one 32-bit transfer.
> 
>   fbdev also clears the lines with hardware blitting, which is much
>   faster than clearing it with memcpy.
> 
>   Based on your recommendation i also verified that pci coalescing is
>   enabled.
> 
>   These numbers are with DRM's unnatural scrolling behaviour - it seems
>   to scroll several (text)lines at once if it takes to much time. I
>   guess if DRM would scroll line by line it would be even slower.
> 
>   If DRM would add those things - hardware clearing of memory regions,
>   hw blitting for text with a FG/BG color and modesetting i wouldn't
>   care about fbdev at all. But right now, it's working way faster for me.

A DRM driver can implement the same fbdev acceleration hooks as an fbdev driver.

(Most DRM drivers never bothered because the HW is more complex than traditional 2D accelerators, and can't safely be used under all circumstances where fbdev acceleration hooks could get called from. That's not an issue for a traditional 2D accelerator driver though)


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer