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: <87h7a1l5pn.fsf@x1.stackframe.org>
Date:   Tue, 18 Jan 2022 11:05:08 +0100
From:   Sven Schnelle <svens@...ckframe.org>
To:     Michel Dänzer <michel.daenzer@...lbox.org>
Cc:     Thomas Zimmermann <tzimmermann@...e.de>,
        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

Hi Michel,

Michel Dänzer <michel.daenzer@...lbox.org> writes:

> 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.

But i guess i can still only use the DRM_FORMAT_* encodings with that?
What i need is a pixel bitmap with separate FG/BG colors. Is that
possible?

/Sven