Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Sven Schnelle <svens@stackframe.org>
To:     Michel =?utf-8?Q?D=C3=A4nzer?= <michel.daenzer@mailbox.org>
Cc:     Thomas Zimmermann <tzimmermann@suse.de>,
        Helge Deller <deller@gmx.de>, linux-fbdev@vger.kernel.org,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
References: <YeG8ydoJNWWkGrTb@ls3530>
        <c48ad8ae-aea5-43fa-882f-dccb90dde9a4@suse.de>
        <87bl0amc6s.fsf@x1.stackframe.org>
        <a922343d-8805-3446-c000-cf7969699823@mailbox.org>
Date:   Tue, 18 Jan 2022 11:05:08 +0100
In-Reply-To: <a922343d-8805-3446-c000-cf7969699823@mailbox.org> ("Michel
        =?utf-8?Q?D=C3=A4nzer=22's?= message of "Tue, 18 Jan 2022 09:58:13 +0100")
Message-ID: <87h7a1l5pn.fsf@x1.stackframe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Michel,

Michel D=C3=A4nzer <michel.daenzer@mailbox.org> writes:

> On 2022-01-17 19:47, Sven Schnelle wrote:
>>=20
>>>  * 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.
>>=20
>> 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].
>>=20
>> Based on your recommendation i re-wrote the whole thing in DRM. This
>> works but has several drawbacks:
>>=20
>> - no modesetting. With fbdev, i can nicely switch resolutions with
>>   fbset. That doesn't work, and i've been told that this is not supporte=
d[2]
>>=20
>> - 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.
>>=20
>>   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.
>>=20
>>   fbdev also clears the lines with hardware blitting, which is much
>>   faster than clearing it with memcpy.
>>=20
>>   Based on your recommendation i also verified that pci coalescing is
>>   enabled.
>>=20
>>   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.
>>=20
>>   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