[PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

The fbdev layer is orphaned, but seems to need some care.
So I'd like to step up as new maintainer.

Signed-off-by: Helge Deller <deller@gmx.de>

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d0cd537803a..ce47dbc467cc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7583,11 +7583,12 @@ W:	http://floatingpoint.sourceforge.net/emulator/index.html
 F:	arch/x86/math-emu/

 FRAMEBUFFER LAYER
-L:	dri-devel@lists.freedesktop.org
+M:	Helge Deller <deller@gmx.de>
 L:	linux-fbdev@vger.kernel.org
-S:	Orphan
+L:	dri-devel@lists.freedesktop.org
+S:	Maintained
 Q:	http://patchwork.kernel.org/project/linux-fbdev/list/
-T:	git git://anongit.freedesktop.org/drm/drm-misc
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
 F:	Documentation/fb/
 F:	drivers/video/
 F:	include/linux/fb.h

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Helge,

On Fri, Jan 14, 2022 at 7:12 PM Helge Deller <deller@gmx.de> wrote:
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
>
> Signed-off-by: Helge Deller <deller@gmx.de>

Thanks a lot!

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Helge,

On Fri, Jan 14, 2022 at 7:12 PM Helge Deller <deller@gmx.de> wrote:
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
>
> Signed-off-by: Helge Deller <deller@gmx.de>

Thanks a lot!

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Hi Helge

On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d0cd537803a..ce47dbc467cc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>  F:     arch/x86/math-emu/
>
>  FRAMEBUFFER LAYER
> -L:     dri-devel@lists.freedesktop.org
> +M:     Helge Deller <deller@gmx.de>
>  L:     linux-fbdev@vger.kernel.org
> -S:     Orphan
> +L:     dri-devel@lists.freedesktop.org
> +S:     Maintained
>  Q:     http://patchwork.kernel.org/project/linux-fbdev/list/
> -T:     git git://anongit.freedesktop.org/drm/drm-misc
> +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git

Maybe don't rush maintainer changes in over the w/e without even bothering
to get any input from the people who've been maintaining it before.

Because the status isn't entirely correct, fbdev core code and fbcon and
all that has been maintained, but in bugfixes only mode. And there's very
solid&important reasons to keep merging these patches through a drm tree,
because that's where all the driver development happens, and hence also
all the testing (e.g. the drm test suite has some fbdev tests - the only
automated ones that exist to my knowledge - and we run them in CI). So
moving that into an obscure new tree which isn't even in linux-next yet is
no good at all.

Now fbdev driver bugfixes is indeed practically orphaned and I very much
welcome anyone stepping up for that, but the simplest approach there would
be to just get drm-misc commit rights and push the oddball bugfix in there
directly. But also if you want to do your own pull requests to Linus for
that I don't care and there's really no interference, so whatever floats.

But any code that is relevant for drm drivers really needs to in through
drm trees, nothing else makes much sense.

I guess you're first action as newly minted maintainer is going to be to
clean up the confusion you just created.

Cheers, Daniel

>  F:     Documentation/fb/
>  F:     drivers/video/
>  F:     include/linux/fb.h



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

Hi Helge

On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d0cd537803a..ce47dbc467cc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>  F:     arch/x86/math-emu/
>
>  FRAMEBUFFER LAYER
> -L:     dri-devel@lists.freedesktop.org
> +M:     Helge Deller <deller@gmx.de>
>  L:     linux-fbdev@vger.kernel.org
> -S:     Orphan
> +L:     dri-devel@lists.freedesktop.org
> +S:     Maintained
>  Q:     http://patchwork.kernel.org/project/linux-fbdev/list/
> -T:     git git://anongit.freedesktop.org/drm/drm-misc
> +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git

Maybe don't rush maintainer changes in over the w/e without even bothering
to get any input from the people who've been maintaining it before.

Because the status isn't entirely correct, fbdev core code and fbcon and
all that has been maintained, but in bugfixes only mode. And there's very
solid&important reasons to keep merging these patches through a drm tree,
because that's where all the driver development happens, and hence also
all the testing (e.g. the drm test suite has some fbdev tests - the only
automated ones that exist to my knowledge - and we run them in CI). So
moving that into an obscure new tree which isn't even in linux-next yet is
no good at all.

Now fbdev driver bugfixes is indeed practically orphaned and I very much
welcome anyone stepping up for that, but the simplest approach there would
be to just get drm-misc commit rights and push the oddball bugfix in there
directly. But also if you want to do your own pull requests to Linus for
that I don't care and there's really no interference, so whatever floats.

But any code that is relevant for drm drivers really needs to in through
drm trees, nothing else makes much sense.

I guess you're first action as newly minted maintainer is going to be to
clean up the confusion you just created.

Cheers, Daniel

>  F:     Documentation/fb/
>  F:     drivers/video/
>  F:     include/linux/fb.h



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

Hi Helge

On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d0cd537803a..ce47dbc467cc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>  F:     arch/x86/math-emu/
>
>  FRAMEBUFFER LAYER
> -L:     dri-devel@lists.freedesktop.org
> +M:     Helge Deller <deller@gmx.de>
>  L:     linux-fbdev@vger.kernel.org
> -S:     Orphan

Maybe don't rush maintainer changes in over the w/e without even bothering
to get any input from the people who've been maintaining it before.

Because the status isn't entirely correct, fbdev core code and fbcon and
all that has been maintained, but in bugfixes only mode. And there's very
solid&important reasons to keep merging these patches through a drm tree,
because that's where all the driver development happens, and hence also
all the testing (e.g. the drm test suite has some fbdev tests - the only
automated ones that exist to my knowledge - and we run them in CI). So
moving that into an obscure new tree which isn't even in linux-next yet is
no good at all.

Now fbdev driver bugfixes is indeed practically orphaned and I very much
welcome anyone stepping up for that, but the simplest approach there would
be to just get drm-misc commit rights and push the oddball bugfix in there
directly. But also if you want to do your own pull requests to Linus for
that I don't care and there's really no interference I think, so
whatever floats.

But any code that is relevant for drm drivers really needs to go in through
drm trees, nothing else makes much sense.

I guess you're first action as newly minted fbdev maintainer is going to be to
clean up the confusion you just created.

Cheers, Daniel


> +L:     dri-devel@lists.freedesktop.org
> +S:     Maintained
>  Q:     http://patchwork.kernel.org/project/linux-fbdev/list/
> -T:     git git://anongit.freedesktop.org/drm/drm-misc
> +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>  F:     Documentation/fb/
>  F:     drivers/video/
>  F:     include/linux/fb.h



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

Hi Helge

On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d0cd537803a..ce47dbc467cc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>  F:     arch/x86/math-emu/
>
>  FRAMEBUFFER LAYER
> -L:     dri-devel@lists.freedesktop.org
> +M:     Helge Deller <deller@gmx.de>
>  L:     linux-fbdev@vger.kernel.org
> -S:     Orphan

Maybe don't rush maintainer changes in over the w/e without even bothering
to get any input from the people who've been maintaining it before.

Because the status isn't entirely correct, fbdev core code and fbcon and
all that has been maintained, but in bugfixes only mode. And there's very
solid&important reasons to keep merging these patches through a drm tree,
because that's where all the driver development happens, and hence also
all the testing (e.g. the drm test suite has some fbdev tests - the only
automated ones that exist to my knowledge - and we run them in CI). So
moving that into an obscure new tree which isn't even in linux-next yet is
no good at all.

Now fbdev driver bugfixes is indeed practically orphaned and I very much
welcome anyone stepping up for that, but the simplest approach there would
be to just get drm-misc commit rights and push the oddball bugfix in there
directly. But also if you want to do your own pull requests to Linus for
that I don't care and there's really no interference I think, so
whatever floats.

But any code that is relevant for drm drivers really needs to go in through
drm trees, nothing else makes much sense.

I guess you're first action as newly minted fbdev maintainer is going to be to
clean up the confusion you just created.

Cheers, Daniel


> +L:     dri-devel@lists.freedesktop.org
> +S:     Maintained
>  Q:     http://patchwork.kernel.org/project/linux-fbdev/list/
> -T:     git git://anongit.freedesktop.org/drm/drm-misc
> +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>  F:     Documentation/fb/
>  F:     drivers/video/
>  F:     include/linux/fb.h



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Javier Martinez Canillas]

On 1/17/22 11:02, Daniel Vetter wrote:

[snip]

>>  FRAMEBUFFER LAYER
>> -L:     dri-devel@lists.freedesktop.org
>> +M:     Helge Deller <deller@gmx.de>
>>  L:     linux-fbdev@vger.kernel.org
>> -S:     Orphan
> 
> Maybe don't rush maintainer changes in over the w/e without even bothering
> to get any input from the people who've been maintaining it before.
> 
> Because the status isn't entirely correct, fbdev core code and fbcon and
> all that has been maintained, but in bugfixes only mode. And there's very
> solid&important reasons to keep merging these patches through a drm tree,
> because that's where all the driver development happens, and hence also
> all the testing (e.g. the drm test suite has some fbdev tests - the only
> automated ones that exist to my knowledge - and we run them in CI). So
> moving that into an obscure new tree which isn't even in linux-next yet is
> no good at all.
> 
> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> welcome anyone stepping up for that, but the simplest approach there would
> be to just get drm-misc commit rights and push the oddball bugfix in there
> directly. But also if you want to do your own pull requests to Linus for
> that I don't care and there's really no interference I think, so
> whatever floats.
>

I second that getting commit rights in drm-misc and pushing the changes
there makes much more sense than keeping a separate tree for fbdev.

Not only for the fbdev core and fbcon but also for fbdev drivers. There
is common for fbdev drivers bugs to be exposed after DRM changes, so it
is more convenient to push fixes for these through the same tree as well.

As an example, just last week I had to fix issues in the vga16fb driver
that started to occur after a change to support simpledrm in aarch64:

https://lore.kernel.org/all/20220111131601.u36j6grsvnir5gvp@houat/T/

If there is a separate tree for fbdev, then this would require to do
some coordination, share and merge immutable branches, etc for no
clear benefit.

Best regards,-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Javier Martinez Canillas]

On 1/17/22 11:02, Daniel Vetter wrote:

[snip]

>>  FRAMEBUFFER LAYER
>> -L:     dri-devel@lists.freedesktop.org
>> +M:     Helge Deller <deller@gmx.de>
>>  L:     linux-fbdev@vger.kernel.org
>> -S:     Orphan
> 
> Maybe don't rush maintainer changes in over the w/e without even bothering
> to get any input from the people who've been maintaining it before.
> 
> Because the status isn't entirely correct, fbdev core code and fbcon and
> all that has been maintained, but in bugfixes only mode. And there's very
> solid&important reasons to keep merging these patches through a drm tree,
> because that's where all the driver development happens, and hence also
> all the testing (e.g. the drm test suite has some fbdev tests - the only
> automated ones that exist to my knowledge - and we run them in CI). So
> moving that into an obscure new tree which isn't even in linux-next yet is
> no good at all.
> 
> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> welcome anyone stepping up for that, but the simplest approach there would
> be to just get drm-misc commit rights and push the oddball bugfix in there
> directly. But also if you want to do your own pull requests to Linus for
> that I don't care and there's really no interference I think, so
> whatever floats.
>

I second that getting commit rights in drm-misc and pushing the changes
there makes much more sense than keeping a separate tree for fbdev.

Not only for the fbdev core and fbcon but also for fbdev drivers. There
is common for fbdev drivers bugs to be exposed after DRM changes, so it
is more convenient to push fixes for these through the same tree as well.

As an example, just last week I had to fix issues in the vga16fb driver
that started to occur after a change to support simpledrm in aarch64:

https://lore.kernel.org/all/20220111131601.u36j6grsvnir5gvp@houat/T/

If there is a separate tree for fbdev, then this would require to do
some coordination, share and merge immutable branches, etc for no
clear benefit.

Best regards,-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Jani Nikula]

On Mon, 17 Jan 2022, Daniel Vetter <daniel@ffwll.ch> wrote:
> Hi Helge
>
> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>
>> The fbdev layer is orphaned, but seems to need some care.
>> So I'd like to step up as new maintainer.
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d0cd537803a..ce47dbc467cc 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>  F:     arch/x86/math-emu/
>>
>>  FRAMEBUFFER LAYER
>> -L:     dri-devel@lists.freedesktop.org
>> +M:     Helge Deller <deller@gmx.de>
>>  L:     linux-fbdev@vger.kernel.org
>> -S:     Orphan
>
> Maybe don't rush maintainer changes in over the w/e without even bothering
> to get any input from the people who've been maintaining it before.
>
> Because the status isn't entirely correct, fbdev core code and fbcon and
> all that has been maintained, but in bugfixes only mode. And there's very
> solid&important reasons to keep merging these patches through a drm tree,
> because that's where all the driver development happens, and hence also
> all the testing (e.g. the drm test suite has some fbdev tests - the only
> automated ones that exist to my knowledge - and we run them in CI). So
> moving that into an obscure new tree which isn't even in linux-next yet is
> no good at all.
>
> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> welcome anyone stepping up for that, but the simplest approach there would
> be to just get drm-misc commit rights and push the oddball bugfix in there
> directly. But also if you want to do your own pull requests to Linus for
> that I don't care and there's really no interference I think, so
> whatever floats.
>
> But any code that is relevant for drm drivers really needs to go in through
> drm trees, nothing else makes much sense.
>
> I guess you're first action as newly minted fbdev maintainer is going to be to
> clean up the confusion you just created.

As much as I like folks stepping up as maintainers, I've got to say this
is not a style I appreciate at all.

Thursday: Object a recent fbdev change [1].

Friday: Step up as fbdev maintainer, change git tree (this thread) [2].

Sunday: Send the maintainer change to Linus [3].

Later Sunday: Start reverting the changes objected to on Thursday, with
no discussion, no acks, no reviews, in the new git tree [4].

Monday: Continue reverting the changes [5].

I'm heavily in favor of maintainers who are open, transparent,
collaborative, who seek consensus through discussion, and only put their
foot down when required.

I really don't like the optics here. I'd expect some pretty good
explanations.


BR,
Jani.


[1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
[2] https://lore.kernel.org/r/YeG8ydoJNWWkGrTb@ls3530
[3] https://lore.kernel.org/r/YeRyfaesC2kxkgZC@ls3530
[4] https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=a8005a65d06cfb89585574d956d80b6e23012caa
[5] https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=9a89eeda722231fd1079dbfab4a9769b4beb868d


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hello Jani,

On 1/17/22 11:49, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Daniel Vetter <daniel@ffwll.ch> wrote:
>> Hi Helge
>>
>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>
>>> The fbdev layer is orphaned, but seems to need some care.
>>> So I'd like to step up as new maintainer.
>>>
>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 5d0cd537803a..ce47dbc467cc 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>  F:     arch/x86/math-emu/
>>>
>>>  FRAMEBUFFER LAYER
>>> -L:     dri-devel@lists.freedesktop.org
>>> +M:     Helge Deller <deller@gmx.de>
>>>  L:     linux-fbdev@vger.kernel.org
>>> -S:     Orphan
>>
>> Maybe don't rush maintainer changes in over the w/e without even bothering
>> to get any input from the people who've been maintaining it before.
>>
>> Because the status isn't entirely correct, fbdev core code and fbcon and
>> all that has been maintained, but in bugfixes only mode. And there's very
>> solid&important reasons to keep merging these patches through a drm tree,
>> because that's where all the driver development happens, and hence also
>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>> automated ones that exist to my knowledge - and we run them in CI). So
>> moving that into an obscure new tree which isn't even in linux-next yet is
>> no good at all.
>>
>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>> welcome anyone stepping up for that, but the simplest approach there would
>> be to just get drm-misc commit rights and push the oddball bugfix in there
>> directly. But also if you want to do your own pull requests to Linus for
>> that I don't care and there's really no interference I think, so
>> whatever floats.
>>
>> But any code that is relevant for drm drivers really needs to go in through
>> drm trees, nothing else makes much sense.
>>
>> I guess you're first action as newly minted fbdev maintainer is going to be to
>> clean up the confusion you just created.
>
> As much as I like folks stepping up as maintainers, I've got to say this
> is not a style I appreciate at all.
>
> Thursday: Object a recent fbdev change [1].
>
> Friday: Step up as fbdev maintainer, change git tree (this thread) [2].
>
> Sunday: Send the maintainer change to Linus [3].
>
> Later Sunday: Start reverting the changes objected to on Thursday, with
> no discussion, no acks, no reviews, in the new git tree [4].
>
> Monday: Continue reverting the changes [5].
>
> I'm heavily in favor of maintainers who are open, transparent,
> collaborative, who seek consensus through discussion, and only put their
> foot down when required.
>
> I really don't like the optics here. I'd expect some pretty good
> explanations.

Jani, please don't worry!
I've started to sort things out, to work through the existing backlog of
patches (which is a LOT!) and nothing has been pushed yet.
I've seen the other mails and we will discuss.

So, please just ignore the current state of the linux-fbdev tree for now.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hello Daniel,

On 1/17/22 11:02, Daniel Vetter wrote:
> Hi Helge
>
> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>
>> The fbdev layer is orphaned, but seems to need some care.
>> So I'd like to step up as new maintainer.
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d0cd537803a..ce47dbc467cc 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>  F:     arch/x86/math-emu/
>>
>>  FRAMEBUFFER LAYER
>> -L:     dri-devel@lists.freedesktop.org
>> +M:     Helge Deller <deller@gmx.de>
>>  L:     linux-fbdev@vger.kernel.org
>> -S:     Orphan
>
> Maybe don't rush maintainer changes in over the w/e without even bothering
> to get any input from the people who've been maintaining it before.
>
> Because the status isn't entirely correct, fbdev core code and fbcon and
> all that has been maintained, but in bugfixes only mode. And there's very
> solid&important reasons to keep merging these patches through a drm tree,
> because that's where all the driver development happens, and hence also
> all the testing (e.g. the drm test suite has some fbdev tests - the only
> automated ones that exist to my knowledge - and we run them in CI). So
> moving that into an obscure new tree which isn't even in linux-next yet is
> no good at all.
>
> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> welcome anyone stepping up for that, but the simplest approach there would
> be to just get drm-misc commit rights and push the oddball bugfix in there
> directly. But also if you want to do your own pull requests to Linus for
> that I don't care and there's really no interference I think, so
> whatever floats.
>
> But any code that is relevant for drm drivers really needs to go in through
> drm trees, nothing else makes much sense.
>
> I guess you're first action as newly minted fbdev maintainer is going to be to
> clean up the confusion you just created.

Most of my machines depend on a working fbdev layer since drm isn't (and probably
-due to technical requirements of DRM- won't be) available for those.
So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.

I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
For me it's really not important to drive any patches through a seperate tree, so
I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
adding my tree to for-next was on my todo list...)

What's important for me though is, to keep fbdev actively maintained, which means:
a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
   I know of at least one driver which won't be able to support DRM....
   Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
   either when run on native hardware or in an emulator.
d) not break DRM development

Especially regarding c) I complained in [1] and got no feedback. I really would like to
understand where the actual problems were and what's necessary to fix them.

Helge

[1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hello Daniel,

On 1/17/22 11:02, Daniel Vetter wrote:
> Hi Helge
>
> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>
>> The fbdev layer is orphaned, but seems to need some care.
>> So I'd like to step up as new maintainer.
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d0cd537803a..ce47dbc467cc 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>  F:     arch/x86/math-emu/
>>
>>  FRAMEBUFFER LAYER
>> -L:     dri-devel@lists.freedesktop.org
>> +M:     Helge Deller <deller@gmx.de>
>>  L:     linux-fbdev@vger.kernel.org
>> -S:     Orphan
>
> Maybe don't rush maintainer changes in over the w/e without even bothering
> to get any input from the people who've been maintaining it before.
>
> Because the status isn't entirely correct, fbdev core code and fbcon and
> all that has been maintained, but in bugfixes only mode. And there's very
> solid&important reasons to keep merging these patches through a drm tree,
> because that's where all the driver development happens, and hence also
> all the testing (e.g. the drm test suite has some fbdev tests - the only
> automated ones that exist to my knowledge - and we run them in CI). So
> moving that into an obscure new tree which isn't even in linux-next yet is
> no good at all.
>
> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> welcome anyone stepping up for that, but the simplest approach there would
> be to just get drm-misc commit rights and push the oddball bugfix in there
> directly. But also if you want to do your own pull requests to Linus for
> that I don't care and there's really no interference I think, so
> whatever floats.
>
> But any code that is relevant for drm drivers really needs to go in through
> drm trees, nothing else makes much sense.
>
> I guess you're first action as newly minted fbdev maintainer is going to be to
> clean up the confusion you just created.

Most of my machines depend on a working fbdev layer since drm isn't (and probably
-due to technical requirements of DRM- won't be) available for those.
So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.

I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
For me it's really not important to drive any patches through a seperate tree, so
I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
adding my tree to for-next was on my todo list...)

What's important for me though is, to keep fbdev actively maintained, which means:
a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
   I know of at least one driver which won't be able to support DRM....
   Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
   either when run on native hardware or in an emulator.
d) not break DRM development

Especially regarding c) I complained in [1] and got no feedback. I really would like to
understand where the actual problems were and what's necessary to fix them.

Helge

[1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>    I know of at least one driver which won't be able to support DRM....

Hmm?  I seriously doubt that.  There is always the option to use a
shadow framebuffer, then convert from standard drm formats to whatever
esoteric pixel format your hardware expects.

Been there, done that.  Have a look at the cirrus driver.  The physical
hardware was designed in the early 90-ies, almost 30 years ago.  These
days it exists in virtual form only (qemu emulates it).  Thanks to the
drm driver it runs wayland just fine even though it has a bunch of
constrains dictated by the hardware design.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>    I know of at least one driver which won't be able to support DRM....

Hmm?  I seriously doubt that.  There is always the option to use a
shadow framebuffer, then convert from standard drm formats to whatever
esoteric pixel format your hardware expects.

Been there, done that.  Have a look at the cirrus driver.  The physical
hardware was designed in the early 90-ies, almost 30 years ago.  These
days it exists in virtual form only (qemu emulates it).  Thanks to the
drm driver it runs wayland just fine even though it has a bunch of
constrains dictated by the hardware design.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Gerd,

On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >    I know of at least one driver which won't be able to support DRM....
>
> Hmm?  I seriously doubt that.  There is always the option to use a
> shadow framebuffer, then convert from standard drm formats to whatever
> esoteric pixel format your hardware expects.
>
> Been there, done that.  Have a look at the cirrus driver.  The physical
> hardware was designed in the early 90-ies, almost 30 years ago.  These
> days it exists in virtual form only (qemu emulates it).  Thanks to the
> drm driver it runs wayland just fine even though it has a bunch of
> constrains dictated by the hardware design.

The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
modes only.  The Cirrus fbdev driver also supports mochrome and 256
color modes.

There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
frame buffer to convert from truecolor to 256 colors would be doable,
but would give bad results. And what about less colors?
Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
the DRM core assumes in many places that a pixel is at least 1 byte,
and would crash otherwise (yes I tried).  Other modes needed are
DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
This not only to support "old" hardware, but also modern small OLED
and e-ink displays.

On the positive side: DRM would force e.g. the Amiga and Atari
bitplane formats to become internal to the kernel driver, with the
kernel driver converting from packed pixels to bitplanes.  Hence
userspace would no longer have to care about bitplanes.


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Gerd,

On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >    I know of at least one driver which won't be able to support DRM....
>
> Hmm?  I seriously doubt that.  There is always the option to use a
> shadow framebuffer, then convert from standard drm formats to whatever
> esoteric pixel format your hardware expects.
>
> Been there, done that.  Have a look at the cirrus driver.  The physical
> hardware was designed in the early 90-ies, almost 30 years ago.  These
> days it exists in virtual form only (qemu emulates it).  Thanks to the
> drm driver it runs wayland just fine even though it has a bunch of
> constrains dictated by the hardware design.

The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
modes only.  The Cirrus fbdev driver also supports mochrome and 256
color modes.

There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
frame buffer to convert from truecolor to 256 colors would be doable,
but would give bad results. And what about less colors?
Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
the DRM core assumes in many places that a pixel is at least 1 byte,
and would crash otherwise (yes I tried).  Other modes needed are
DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
This not only to support "old" hardware, but also modern small OLED
and e-ink displays.

On the positive side: DRM would force e.g. the Amiga and Atari
bitplane formats to become internal to the kernel driver, with the
kernel driver converting from packed pixels to bitplanes.  Hence
userspace would no longer have to care about bitplanes.


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 3006 bytes --]

Hi

Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
> Hi Gerd,
> 
> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>     I know of at least one driver which won't be able to support DRM....
>>
>> Hmm?  I seriously doubt that.  There is always the option to use a
>> shadow framebuffer, then convert from standard drm formats to whatever
>> esoteric pixel format your hardware expects.
>>
>> Been there, done that.  Have a look at the cirrus driver.  The physical
>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>> drm driver it runs wayland just fine even though it has a bunch of
>> constrains dictated by the hardware design.
> 
> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> modes only.  The Cirrus fbdev driver also supports mochrome and 256
> color modes.
> 
> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
> frame buffer to convert from truecolor to 256 colors would be doable,
> but would give bad results. And what about less colors?
> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
> the DRM core assumes in many places that a pixel is at least 1 byte,
> and would crash otherwise (yes I tried).  Other modes needed are
> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).

We export XRGB32 from each driver, because userspace expects it. But 
that is not a hard requirement. Userspace can use any format. It's just 
that no one seems to have any use cases so far, so no work has been 
done. Think of XRGB32 as a fallback.

Personally, I'd much appreciate if userspace would support more of the 
native formats and not rely on XRGB32.


> This not only to support "old" hardware, but also modern small OLED
> and e-ink displays.

There's a DRM driver for Repaper e-Ink displays. So it seems doable at 
least.

Best regards
Thomas

> 
> On the positive side: DRM would force e.g. the Amiga and Atari
> bitplane formats to become internal to the kernel driver, with the
> kernel driver converting from packed pixels to bitplanes.  Hence
> userspace would no longer have to care about bitplanes.
> 
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 3006 bytes --]

Hi

Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
> Hi Gerd,
> 
> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>     I know of at least one driver which won't be able to support DRM....
>>
>> Hmm?  I seriously doubt that.  There is always the option to use a
>> shadow framebuffer, then convert from standard drm formats to whatever
>> esoteric pixel format your hardware expects.
>>
>> Been there, done that.  Have a look at the cirrus driver.  The physical
>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>> drm driver it runs wayland just fine even though it has a bunch of
>> constrains dictated by the hardware design.
> 
> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> modes only.  The Cirrus fbdev driver also supports mochrome and 256
> color modes.
> 
> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
> frame buffer to convert from truecolor to 256 colors would be doable,
> but would give bad results. And what about less colors?
> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
> the DRM core assumes in many places that a pixel is at least 1 byte,
> and would crash otherwise (yes I tried).  Other modes needed are
> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).

We export XRGB32 from each driver, because userspace expects it. But 
that is not a hard requirement. Userspace can use any format. It's just 
that no one seems to have any use cases so far, so no work has been 
done. Think of XRGB32 as a fallback.

Personally, I'd much appreciate if userspace would support more of the 
native formats and not rely on XRGB32.


> This not only to support "old" hardware, but also modern small OLED
> and e-ink displays.

There's a DRM driver for Repaper e-Ink displays. So it seems doable at 
least.

Best regards
Thomas

> 
> On the positive side: DRM would force e.g. the Amiga and Atari
> bitplane formats to become internal to the kernel driver, with the
> kernel driver converting from packed pixels to bitplanes.  Hence
> userspace would no longer have to care about bitplanes.
> 
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Thomas,

On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
> > On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >>>     I know of at least one driver which won't be able to support DRM....
> >>
> >> Hmm?  I seriously doubt that.  There is always the option to use a
> >> shadow framebuffer, then convert from standard drm formats to whatever
> >> esoteric pixel format your hardware expects.
> >>
> >> Been there, done that.  Have a look at the cirrus driver.  The physical
> >> hardware was designed in the early 90-ies, almost 30 years ago.  These
> >> days it exists in virtual form only (qemu emulates it).  Thanks to the
> >> drm driver it runs wayland just fine even though it has a bunch of
> >> constrains dictated by the hardware design.
> >
> > The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> > modes only.  The Cirrus fbdev driver also supports mochrome and 256
> > color modes.
> >
> > There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> > the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
> > frame buffer to convert from truecolor to 256 colors would be doable,
> > but would give bad results. And what about less colors?
> > Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
> > the DRM core assumes in many places that a pixel is at least 1 byte,
> > and would crash otherwise (yes I tried).  Other modes needed are
> > DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
>
> We export XRGB32 from each driver, because userspace expects it. But
> that is not a hard requirement. Userspace can use any format. It's just
> that no one seems to have any use cases so far, so no work has been
> done. Think of XRGB32 as a fallback.

Using an XRGB32 intermediate would kill the user experience on old
machines, due to both increased memory usage and copy overhead.

> Personally, I'd much appreciate if userspace would support more of the
> native formats and not rely on XRGB32.

Supporting monochrome, 16 colors, and 256 colors would be nice.

> > This not only to support "old" hardware, but also modern small OLED
> > and e-ink displays.
>
> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
> least.

Which uses an DRM_FORMAT_XRGB8888 intermediate, and
drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
to convert from truecolor to monochrome.  I guess that would work,
as this is a slow e-ink display.  Have fun as a text console ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Thomas,

On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
> > On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >>>     I know of at least one driver which won't be able to support DRM....
> >>
> >> Hmm?  I seriously doubt that.  There is always the option to use a
> >> shadow framebuffer, then convert from standard drm formats to whatever
> >> esoteric pixel format your hardware expects.
> >>
> >> Been there, done that.  Have a look at the cirrus driver.  The physical
> >> hardware was designed in the early 90-ies, almost 30 years ago.  These
> >> days it exists in virtual form only (qemu emulates it).  Thanks to the
> >> drm driver it runs wayland just fine even though it has a bunch of
> >> constrains dictated by the hardware design.
> >
> > The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> > modes only.  The Cirrus fbdev driver also supports mochrome and 256
> > color modes.
> >
> > There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> > the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
> > frame buffer to convert from truecolor to 256 colors would be doable,
> > but would give bad results. And what about less colors?
> > Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
> > the DRM core assumes in many places that a pixel is at least 1 byte,
> > and would crash otherwise (yes I tried).  Other modes needed are
> > DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
>
> We export XRGB32 from each driver, because userspace expects it. But
> that is not a hard requirement. Userspace can use any format. It's just
> that no one seems to have any use cases so far, so no work has been
> done. Think of XRGB32 as a fallback.

Using an XRGB32 intermediate would kill the user experience on old
machines, due to both increased memory usage and copy overhead.

> Personally, I'd much appreciate if userspace would support more of the
> native formats and not rely on XRGB32.

Supporting monochrome, 16 colors, and 256 colors would be nice.

> > This not only to support "old" hardware, but also modern small OLED
> > and e-ink displays.
>
> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
> least.

Which uses an DRM_FORMAT_XRGB8888 intermediate, and
drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
to convert from truecolor to monochrome.  I guess that would work,
as this is a slow e-ink display.  Have fun as a text console ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 15:10, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
>>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>>>     I know of at least one driver which won't be able to support DRM....
>>>>
>>>> Hmm?  I seriously doubt that.  There is always the option to use a
>>>> shadow framebuffer, then convert from standard drm formats to whatever
>>>> esoteric pixel format your hardware expects.
>>>>
>>>> Been there, done that.  Have a look at the cirrus driver.  The physical
>>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>>>> drm driver it runs wayland just fine even though it has a bunch of
>>>> constrains dictated by the hardware design.
>>>
>>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
>>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
>>> color modes.
>>>
>>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
>>> frame buffer to convert from truecolor to 256 colors would be doable,
>>> but would give bad results. And what about less colors?
>>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
>>> the DRM core assumes in many places that a pixel is at least 1 byte,
>>> and would crash otherwise (yes I tried).  Other modes needed are
>>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
>>
>> We export XRGB32 from each driver, because userspace expects it. But
>> that is not a hard requirement. Userspace can use any format. It's just
>> that no one seems to have any use cases so far, so no work has been
>> done. Think of XRGB32 as a fallback.
>
> Using an XRGB32 intermediate would kill the user experience on old
> machines, due to both increased memory usage and copy overhead.
>
>> Personally, I'd much appreciate if userspace would support more of the
>> native formats and not rely on XRGB32.
>
> Supporting monochrome, 16 colors, and 256 colors would be nice.

From this conversation it seems DRM completely lacks backwards compatibility,
including a missing 2D bitblt copy.
Isn't that all what's needed and then migrating existing drivers would
be easy ?

Helge


>>> This not only to support "old" hardware, but also modern small OLED
>>> and e-ink displays.
>>
>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>> least.
>
> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
> to convert from truecolor to monochrome.  I guess that would work,
> as this is a slow e-ink display.  Have fun as a text console ;-)
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 15:10, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
>>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>>>     I know of at least one driver which won't be able to support DRM....
>>>>
>>>> Hmm?  I seriously doubt that.  There is always the option to use a
>>>> shadow framebuffer, then convert from standard drm formats to whatever
>>>> esoteric pixel format your hardware expects.
>>>>
>>>> Been there, done that.  Have a look at the cirrus driver.  The physical
>>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>>>> drm driver it runs wayland just fine even though it has a bunch of
>>>> constrains dictated by the hardware design.
>>>
>>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
>>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
>>> color modes.
>>>
>>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
>>> frame buffer to convert from truecolor to 256 colors would be doable,
>>> but would give bad results. And what about less colors?
>>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
>>> the DRM core assumes in many places that a pixel is at least 1 byte,
>>> and would crash otherwise (yes I tried).  Other modes needed are
>>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
>>
>> We export XRGB32 from each driver, because userspace expects it. But
>> that is not a hard requirement. Userspace can use any format. It's just
>> that no one seems to have any use cases so far, so no work has been
>> done. Think of XRGB32 as a fallback.
>
> Using an XRGB32 intermediate would kill the user experience on old
> machines, due to both increased memory usage and copy overhead.
>
>> Personally, I'd much appreciate if userspace would support more of the
>> native formats and not rely on XRGB32.
>
> Supporting monochrome, 16 colors, and 256 colors would be nice.

From this conversation it seems DRM completely lacks backwards compatibility,
including a missing 2D bitblt copy.
Isn't that all what's needed and then migrating existing drivers would
be easy ?

Helge


>>> This not only to support "old" hardware, but also modern small OLED
>>> and e-ink displays.
>>
>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>> least.
>
> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
> to convert from truecolor to monochrome.  I guess that would work,
> as this is a slow e-ink display.  Have fun as a text console ;-)
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 3:48 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 15:10, Geert Uytterhoeven wrote:
> > Hi Thomas,
> >
> > On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
> >>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >>>>>     I know of at least one driver which won't be able to support DRM....
> >>>>
> >>>> Hmm?  I seriously doubt that.  There is always the option to use a
> >>>> shadow framebuffer, then convert from standard drm formats to whatever
> >>>> esoteric pixel format your hardware expects.
> >>>>
> >>>> Been there, done that.  Have a look at the cirrus driver.  The physical
> >>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
> >>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
> >>>> drm driver it runs wayland just fine even though it has a bunch of
> >>>> constrains dictated by the hardware design.
> >>>
> >>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> >>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
> >>> color modes.
> >>>
> >>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> >>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
> >>> frame buffer to convert from truecolor to 256 colors would be doable,
> >>> but would give bad results. And what about less colors?
> >>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
> >>> the DRM core assumes in many places that a pixel is at least 1 byte,
> >>> and would crash otherwise (yes I tried).  Other modes needed are
> >>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
> >>
> >> We export XRGB32 from each driver, because userspace expects it. But
> >> that is not a hard requirement. Userspace can use any format. It's just
> >> that no one seems to have any use cases so far, so no work has been
> >> done. Think of XRGB32 as a fallback.
> >
> > Using an XRGB32 intermediate would kill the user experience on old
> > machines, due to both increased memory usage and copy overhead.
> >
> >> Personally, I'd much appreciate if userspace would support more of the
> >> native formats and not rely on XRGB32.
> >
> > Supporting monochrome, 16 colors, and 256 colors would be nice.
>
> From this conversation it seems DRM completely lacks backwards compatibility,
> including a missing 2D bitblt copy.
> Isn't that all what's needed and then migrating existing drivers would
> be easy ?

Not sure who you talked to, but we have drivers with fbdev bitblt
accel (well, in some cases had, because driver maintainers decided
it's just not worth it and ripped it out again or never merged it).
Also the other discussions about some low-bit formats is pretty much
just a question of extending a few enums and wiring through the fbdev
emulation layer. So the things brought up in this thread thus far are
actually the fairly easy items, which should take at most a handful of
patches to rectify. There's much more nastier issues in fbdev, which
will take serious amounts of development time to fix.

Unfortunately in the past 5+ years absolutely no one stepped up with
actual patches, which is why fbdev was marked as orphaned in
MAINTAINERS.
-Daniel

>
> Helge
>
>
> >>> This not only to support "old" hardware, but also modern small OLED
> >>> and e-ink displays.
> >>
> >> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
> >> least.
> >
> > Which uses an DRM_FORMAT_XRGB8888 intermediate, and
> > drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
> > to convert from truecolor to monochrome.  I guess that would work,
> > as this is a slow e-ink display.  Have fun as a text console ;-)
> >
> > Gr{oetje,eeting}s,
> >
> >                         Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> >                                 -- Linus Torvalds
> >
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 3:48 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 15:10, Geert Uytterhoeven wrote:
> > Hi Thomas,
> >
> > On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
> >>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >>>>>     I know of at least one driver which won't be able to support DRM....
> >>>>
> >>>> Hmm?  I seriously doubt that.  There is always the option to use a
> >>>> shadow framebuffer, then convert from standard drm formats to whatever
> >>>> esoteric pixel format your hardware expects.
> >>>>
> >>>> Been there, done that.  Have a look at the cirrus driver.  The physical
> >>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
> >>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
> >>>> drm driver it runs wayland just fine even though it has a bunch of
> >>>> constrains dictated by the hardware design.
> >>>
> >>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> >>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
> >>> color modes.
> >>>
> >>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> >>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
> >>> frame buffer to convert from truecolor to 256 colors would be doable,
> >>> but would give bad results. And what about less colors?
> >>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
> >>> the DRM core assumes in many places that a pixel is at least 1 byte,
> >>> and would crash otherwise (yes I tried).  Other modes needed are
> >>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
> >>
> >> We export XRGB32 from each driver, because userspace expects it. But
> >> that is not a hard requirement. Userspace can use any format. It's just
> >> that no one seems to have any use cases so far, so no work has been
> >> done. Think of XRGB32 as a fallback.
> >
> > Using an XRGB32 intermediate would kill the user experience on old
> > machines, due to both increased memory usage and copy overhead.
> >
> >> Personally, I'd much appreciate if userspace would support more of the
> >> native formats and not rely on XRGB32.
> >
> > Supporting monochrome, 16 colors, and 256 colors would be nice.
>
> From this conversation it seems DRM completely lacks backwards compatibility,
> including a missing 2D bitblt copy.
> Isn't that all what's needed and then migrating existing drivers would
> be easy ?

Not sure who you talked to, but we have drivers with fbdev bitblt
accel (well, in some cases had, because driver maintainers decided
it's just not worth it and ripped it out again or never merged it).
Also the other discussions about some low-bit formats is pretty much
just a question of extending a few enums and wiring through the fbdev
emulation layer. So the things brought up in this thread thus far are
actually the fairly easy items, which should take at most a handful of
patches to rectify. There's much more nastier issues in fbdev, which
will take serious amounts of development time to fix.

Unfortunately in the past 5+ years absolutely no one stepped up with
actual patches, which is why fbdev was marked as orphaned in
MAINTAINERS.
-Daniel

>
> Helge
>
>
> >>> This not only to support "old" hardware, but also modern small OLED
> >>> and e-ink displays.
> >>
> >> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
> >> least.
> >
> > Which uses an DRM_FORMAT_XRGB8888 intermediate, and
> > drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
> > to convert from truecolor to monochrome.  I guess that would work,
> > as this is a slow e-ink display.  Have fun as a text console ;-)
> >
> > Gr{oetje,eeting}s,
> >
> >                         Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> >                                 -- Linus Torvalds
> >
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 16:03, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 3:48 PM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/17/22 15:10, Geert Uytterhoeven wrote:
>>> Hi Thomas,
>>>
>>> On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
>>>>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>>>>>     I know of at least one driver which won't be able to support DRM....
>>>>>>
>>>>>> Hmm?  I seriously doubt that.  There is always the option to use a
>>>>>> shadow framebuffer, then convert from standard drm formats to whatever
>>>>>> esoteric pixel format your hardware expects.
>>>>>>
>>>>>> Been there, done that.  Have a look at the cirrus driver.  The physical
>>>>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>>>>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>>>>>> drm driver it runs wayland just fine even though it has a bunch of
>>>>>> constrains dictated by the hardware design.
>>>>>
>>>>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
>>>>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
>>>>> color modes.
>>>>>
>>>>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>>>>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
>>>>> frame buffer to convert from truecolor to 256 colors would be doable,
>>>>> but would give bad results. And what about less colors?
>>>>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
>>>>> the DRM core assumes in many places that a pixel is at least 1 byte,
>>>>> and would crash otherwise (yes I tried).  Other modes needed are
>>>>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
>>>>
>>>> We export XRGB32 from each driver, because userspace expects it. But
>>>> that is not a hard requirement. Userspace can use any format. It's just
>>>> that no one seems to have any use cases so far, so no work has been
>>>> done. Think of XRGB32 as a fallback.
>>>
>>> Using an XRGB32 intermediate would kill the user experience on old
>>> machines, due to both increased memory usage and copy overhead.
>>>
>>>> Personally, I'd much appreciate if userspace would support more of the
>>>> native formats and not rely on XRGB32.
>>>
>>> Supporting monochrome, 16 colors, and 256 colors would be nice.
>>
>> From this conversation it seems DRM completely lacks backwards compatibility,
>> including a missing 2D bitblt copy.
>> Isn't that all what's needed and then migrating existing drivers would
>> be easy ?
>
> Not sure who you talked to, but we have drivers with fbdev bitblt
> accel (well, in some cases had, because driver maintainers decided
> it's just not worth it and ripped it out again or never merged it).
> Also the other discussions about some low-bit formats is pretty much
> just a question of extending a few enums and wiring through the fbdev
> emulation layer.

No, you got me wrong.

I'm not talking about making other low-bit formats available to userspace.

I'm talking about running the framebuffer natively on a lower-bit format
and to speed up text emulation (fbcon) with help of on-chip 2D bitblt.
So, similiar as it was done in fbdev for non-DRM graphic cards before two
patches were applied and which disabled this speedup for *all* existing fbdev drivers:
b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next

Esp. the commit message of patch 39aead8373b3 completely
ignored the acceleration of the fbdev drivers.

Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
currently unaccelerated and bound to Truecolour modes only, which is probably
one of the main reasons why most fbdev drivers can't be ported to DRM...

Helge



> So the things brought up in this thread thus far are
> actually the fairly easy items, which should take at most a handful of
> patches to rectify. There's much more nastier issues in fbdev, which
> will take serious amounts of development time to fix.
>
> Unfortunately in the past 5+ years absolutely no one stepped up with
> actual patches, which is why fbdev was marked as orphaned in
> MAINTAINERS.
> -Daniel
>
>>
>> Helge
>>
>>
>>>>> This not only to support "old" hardware, but also modern small OLED
>>>>> and e-ink displays.
>>>>
>>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>>>> least.
>>>
>>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
>>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
>>> to convert from truecolor to monochrome.  I guess that would work,
>>> as this is a slow e-ink display.  Have fun as a text console ;-)
>>>
>>> Gr{oetje,eeting}s,
>>>
>>>                         Geert
>>>
>>> --
>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>>
>>> In personal conversations with technical people, I call myself a hacker. But
>>> when I'm talking to journalists I just say "programmer" or something like that.
>>>                                 -- Linus Torvalds
>>>
>>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 16:03, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 3:48 PM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/17/22 15:10, Geert Uytterhoeven wrote:
>>> Hi Thomas,
>>>
>>> On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:
>>>>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>>>>>     I know of at least one driver which won't be able to support DRM....
>>>>>>
>>>>>> Hmm?  I seriously doubt that.  There is always the option to use a
>>>>>> shadow framebuffer, then convert from standard drm formats to whatever
>>>>>> esoteric pixel format your hardware expects.
>>>>>>
>>>>>> Been there, done that.  Have a look at the cirrus driver.  The physical
>>>>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>>>>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>>>>>> drm driver it runs wayland just fine even though it has a bunch of
>>>>>> constrains dictated by the hardware design.
>>>>>
>>>>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
>>>>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
>>>>> color modes.
>>>>>
>>>>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>>>>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
>>>>> frame buffer to convert from truecolor to 256 colors would be doable,
>>>>> but would give bad results. And what about less colors?
>>>>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
>>>>> the DRM core assumes in many places that a pixel is at least 1 byte,
>>>>> and would crash otherwise (yes I tried).  Other modes needed are
>>>>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).
>>>>
>>>> We export XRGB32 from each driver, because userspace expects it. But
>>>> that is not a hard requirement. Userspace can use any format. It's just
>>>> that no one seems to have any use cases so far, so no work has been
>>>> done. Think of XRGB32 as a fallback.
>>>
>>> Using an XRGB32 intermediate would kill the user experience on old
>>> machines, due to both increased memory usage and copy overhead.
>>>
>>>> Personally, I'd much appreciate if userspace would support more of the
>>>> native formats and not rely on XRGB32.
>>>
>>> Supporting monochrome, 16 colors, and 256 colors would be nice.
>>
>> From this conversation it seems DRM completely lacks backwards compatibility,
>> including a missing 2D bitblt copy.
>> Isn't that all what's needed and then migrating existing drivers would
>> be easy ?
>
> Not sure who you talked to, but we have drivers with fbdev bitblt
> accel (well, in some cases had, because driver maintainers decided
> it's just not worth it and ripped it out again or never merged it).
> Also the other discussions about some low-bit formats is pretty much
> just a question of extending a few enums and wiring through the fbdev
> emulation layer.

No, you got me wrong.

I'm not talking about making other low-bit formats available to userspace.

I'm talking about running the framebuffer natively on a lower-bit format
and to speed up text emulation (fbcon) with help of on-chip 2D bitblt.
So, similiar as it was done in fbdev for non-DRM graphic cards before two
patches were applied and which disabled this speedup for *all* existing fbdev drivers:
b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next

Esp. the commit message of patch 39aead8373b3 completely
ignored the acceleration of the fbdev drivers.

Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
currently unaccelerated and bound to Truecolour modes only, which is probably
one of the main reasons why most fbdev drivers can't be ported to DRM...

Helge



> So the things brought up in this thread thus far are
> actually the fairly easy items, which should take at most a handful of
> patches to rectify. There's much more nastier issues in fbdev, which
> will take serious amounts of development time to fix.
>
> Unfortunately in the past 5+ years absolutely no one stepped up with
> actual patches, which is why fbdev was marked as orphaned in
> MAINTAINERS.
> -Daniel
>
>>
>> Helge
>>
>>
>>>>> This not only to support "old" hardware, but also modern small OLED
>>>>> and e-ink displays.
>>>>
>>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>>>> least.
>>>
>>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
>>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
>>> to convert from truecolor to monochrome.  I guess that would work,
>>> as this is a slow e-ink display.  Have fun as a text console ;-)
>>>
>>> Gr{oetje,eeting}s,
>>>
>>>                         Geert
>>>
>>> --
>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>>
>>> In personal conversations with technical people, I call myself a hacker. But
>>> when I'm talking to journalists I just say "programmer" or something like that.
>>>                                 -- Linus Torvalds
>>>
>>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
> currently unaccelerated and bound to Truecolour modes only,

Yes.  Adding support for formats beside argb8888 to the drm fbcon
emulation shouldn't be that much of a problem though.

Acceleration is harder.  The scroll acceleration had issues nobody
addressed for years, and on modern hardware it is simply not used, which
is probably the reason nobody stepped up fixing things and it ended up
being dropped.  Bringing it back is much more work than just reverting
the commits removing it.

Also note that using a shadow framebuffer allows to decouple fbcon
updates and scanout framebuffer updates.  Can be used to speed up
things without depending on the 2d blitter.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
> currently unaccelerated and bound to Truecolour modes only,

Yes.  Adding support for formats beside argb8888 to the drm fbcon
emulation shouldn't be that much of a problem though.

Acceleration is harder.  The scroll acceleration had issues nobody
addressed for years, and on modern hardware it is simply not used, which
is probably the reason nobody stepped up fixing things and it ended up
being dropped.  Bringing it back is much more work than just reverting
the commits removing it.

Also note that using a shadow framebuffer allows to decouple fbcon
updates and scanout framebuffer updates.  Can be used to speed up
things without depending on the 2d blitter.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Gerd,

On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> Also note that using a shadow framebuffer allows to decouple fbcon
> updates and scanout framebuffer updates.  Can be used to speed up
> things without depending on the 2d blitter.

Assuming accesses to the shadow frame buffer are faster than accesses
to the scanout frame buffer. While this is true on modern hardware,
this is not the case on all hardware.  Especially if the shadow frame
buffer has a higher depth (XRGB8888) than the scanout frame buffer
(e.g. Cn)...

The funny thing is that the systems we are interested in, once used
to be known for their graphics capabilities and/or performance...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Gerd,

On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> Also note that using a shadow framebuffer allows to decouple fbcon
> updates and scanout framebuffer updates.  Can be used to speed up
> things without depending on the 2d blitter.

Assuming accesses to the shadow frame buffer are faster than accesses
to the scanout frame buffer. While this is true on modern hardware,
this is not the case on all hardware.  Especially if the shadow frame
buffer has a higher depth (XRGB8888) than the scanout frame buffer
(e.g. Cn)...

The funny thing is that the systems we are interested in, once used
to be known for their graphics capabilities and/or performance...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 9:10 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Gerd,
>
> On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > Also note that using a shadow framebuffer allows to decouple fbcon
> > updates and scanout framebuffer updates.  Can be used to speed up
> > things without depending on the 2d blitter.
>
> Assuming accesses to the shadow frame buffer are faster than accesses
> to the scanout frame buffer. While this is true on modern hardware,
> this is not the case on all hardware.  Especially if the shadow frame
> buffer has a higher depth (XRGB8888) than the scanout frame buffer
> (e.g. Cn)...
>
> The funny thing is that the systems we are interested in, once used
> to be known for their graphics capabilities and/or performance...

That's just a pure strawman. No one is forcing you to run your shadow
buffer with xrgb8888. You can already do C8, any any other C1 is a few
lines of code. Which I can't type for you, because I don't have such
high performance hardware, but if someone would have spent hacking
instead of typing mails any time this came up the past few years, we'd
have it long ago. It's really not hard.

Same goes for modesetting support in the fbdev emulation layer (that's
a bit more work, but really not much) and really anything. And we do
actually merge additions in the emulation support pretty quickly. If
they show up.
-Daniel

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 9:10 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Gerd,
>
> On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > Also note that using a shadow framebuffer allows to decouple fbcon
> > updates and scanout framebuffer updates.  Can be used to speed up
> > things without depending on the 2d blitter.
>
> Assuming accesses to the shadow frame buffer are faster than accesses
> to the scanout frame buffer. While this is true on modern hardware,
> this is not the case on all hardware.  Especially if the shadow frame
> buffer has a higher depth (XRGB8888) than the scanout frame buffer
> (e.g. Cn)...
>
> The funny thing is that the systems we are interested in, once used
> to be known for their graphics capabilities and/or performance...

That's just a pure strawman. No one is forcing you to run your shadow
buffer with xrgb8888. You can already do C8, any any other C1 is a few
lines of code. Which I can't type for you, because I don't have such
high performance hardware, but if someone would have spent hacking
instead of typing mails any time this came up the past few years, we'd
have it long ago. It's really not hard.

Same goes for modesetting support in the fbdev emulation layer (that's
a bit more work, but really not much) and really anything. And we do
actually merge additions in the emulation support pretty quickly. If
they show up.
-Daniel

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1662 bytes --]

Hi

Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven:
> Hi Gerd,
> 
> On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>> Also note that using a shadow framebuffer allows to decouple fbcon
>> updates and scanout framebuffer updates.  Can be used to speed up
>> things without depending on the 2d blitter.
> 
> Assuming accesses to the shadow frame buffer are faster than accesses
> to the scanout frame buffer. While this is true on modern hardware,
> this is not the case on all hardware.  Especially if the shadow frame
> buffer has a higher depth (XRGB8888) than the scanout frame buffer
> (e.g. Cn)...
> 
> The funny thing is that the systems we are interested in, once used
> to be known for their graphics capabilities and/or performance...

What I still don't understand: why are you so keen on maintaining an 
interface that only serves the console? Nothing else uses fbdev these 
days. Why not improve DRM/userspace to the point where it fits your 
requirements? Long-term, the latter would make a lot more sense.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1662 bytes --]

Hi

Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven:
> Hi Gerd,
> 
> On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>> Also note that using a shadow framebuffer allows to decouple fbcon
>> updates and scanout framebuffer updates.  Can be used to speed up
>> things without depending on the 2d blitter.
> 
> Assuming accesses to the shadow frame buffer are faster than accesses
> to the scanout frame buffer. While this is true on modern hardware,
> this is not the case on all hardware.  Especially if the shadow frame
> buffer has a higher depth (XRGB8888) than the scanout frame buffer
> (e.g. Cn)...
> 
> The funny thing is that the systems we are interested in, once used
> to be known for their graphics capabilities and/or performance...

What I still don't understand: why are you so keen on maintaining an 
interface that only serves the console? Nothing else uses fbdev these 
days. Why not improve DRM/userspace to the point where it fits your 
requirements? Long-term, the latter would make a lot more sense.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Simon Ser]

On Tuesday, January 18th, 2022 at 15:23, Thomas Zimmermann <tzimmermann@suse.de> wrote:

> Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven:
> > Hi Gerd,
> >
> > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >> Also note that using a shadow framebuffer allows to decouple fbcon
> >> updates and scanout framebuffer updates.  Can be used to speed up
> >> things without depending on the 2d blitter.
> >
> > Assuming accesses to the shadow frame buffer are faster than accesses
> > to the scanout frame buffer. While this is true on modern hardware,
> > this is not the case on all hardware.  Especially if the shadow frame
> > buffer has a higher depth (XRGB8888) than the scanout frame buffer
> > (e.g. Cn)...
> >
> > The funny thing is that the systems we are interested in, once used
> > to be known for their graphics capabilities and/or performance...
>
> What I still don't understand: why are you so keen on maintaining an
> interface that only serves the console? Nothing else uses fbdev these
> days. Why not improve DRM/userspace to the point where it fits your
> requirements? Long-term, the latter would make a lot more sense.

+1

If you need any help with adapting user-space, feel free to ping me. I'd be
interested in discussing, providing feedback and potentially user-space
patches.

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Simon Ser]

On Tuesday, January 18th, 2022 at 15:23, Thomas Zimmermann <tzimmermann@suse.de> wrote:

> Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven:
> > Hi Gerd,
> >
> > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >> Also note that using a shadow framebuffer allows to decouple fbcon
> >> updates and scanout framebuffer updates.  Can be used to speed up
> >> things without depending on the 2d blitter.
> >
> > Assuming accesses to the shadow frame buffer are faster than accesses
> > to the scanout frame buffer. While this is true on modern hardware,
> > this is not the case on all hardware.  Especially if the shadow frame
> > buffer has a higher depth (XRGB8888) than the scanout frame buffer
> > (e.g. Cn)...
> >
> > The funny thing is that the systems we are interested in, once used
> > to be known for their graphics capabilities and/or performance...
>
> What I still don't understand: why are you so keen on maintaining an
> interface that only serves the console? Nothing else uses fbdev these
> days. Why not improve DRM/userspace to the point where it fits your
> requirements? Long-term, the latter would make a lot more sense.

+1

If you need any help with adapting user-space, feel free to ping me. I'd be
interested in discussing, providing feedback and potentially user-space
patches.

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> What I still don't understand: why are you so keen on maintaining an
> interface that only serves the console? Nothing else uses fbdev these days.
> Why not improve DRM/userspace to the point where it fits your requirements?
> Long-term, the latter would make a lot more sense.

And note that it is *much* easier to write drm drivers these days.
We got alot of helpers, we got generic fbdev emulation and more.

If you are curious just compare the initial commit of the bochs drm
driver with the current code.  Initially the driver had to manage ttm
and fbdev and whatnot else.  These days writing a (non-accelerated) drm
driver is basically some boilerplate picking the helpers which work best
for your hardware, the code to actually program the hardware and that's
it.

The "new drivers should be drm" policy exists for years already btw,
exactly because of the unfixable fbdev API limitations.  The bochs drm
was a fbdev driver initially.  Never merged.  Got rewritten as drm
driver and that was merged instead.  In 2013, almost a decade ago.

And, yes, it very well might be that drm misses some piece here and
there for specific hardware, such as fbdev emulation not supporting
rgb332.  But I fully agree with Thomas here:  Improving drm is probably
a much better way to spend your time.  drm is where the development
happens.  fbdev is only kept alive.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> What I still don't understand: why are you so keen on maintaining an
> interface that only serves the console? Nothing else uses fbdev these days.
> Why not improve DRM/userspace to the point where it fits your requirements?
> Long-term, the latter would make a lot more sense.

And note that it is *much* easier to write drm drivers these days.
We got alot of helpers, we got generic fbdev emulation and more.

If you are curious just compare the initial commit of the bochs drm
driver with the current code.  Initially the driver had to manage ttm
and fbdev and whatnot else.  These days writing a (non-accelerated) drm
driver is basically some boilerplate picking the helpers which work best
for your hardware, the code to actually program the hardware and that's
it.

The "new drivers should be drm" policy exists for years already btw,
exactly because of the unfixable fbdev API limitations.  The bochs drm
was a fbdev driver initially.  Never merged.  Got rewritten as drm
driver and that was merged instead.  In 2013, almost a decade ago.

And, yes, it very well might be that drm misses some piece here and
there for specific hardware, such as fbdev emulation not supporting
rgb332.  But I fully agree with Thomas here:  Improving drm is probably
a much better way to spend your time.  drm is where the development
happens.  fbdev is only kept alive.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Fri, Jan 21, 2022 at 9:46 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > What I still don't understand: why are you so keen on maintaining an
> > interface that only serves the console? Nothing else uses fbdev these days.
> > Why not improve DRM/userspace to the point where it fits your requirements?
> > Long-term, the latter would make a lot more sense.
>
> And note that it is *much* easier to write drm drivers these days.
> We got alot of helpers, we got generic fbdev emulation and more.
>
> If you are curious just compare the initial commit of the bochs drm
> driver with the current code.  Initially the driver had to manage ttm
> and fbdev and whatnot else.  These days writing a (non-accelerated) drm
> driver is basically some boilerplate picking the helpers which work best
> for your hardware, the code to actually program the hardware and that's
> it.
>
> The "new drivers should be drm" policy exists for years already btw,
> exactly because of the unfixable fbdev API limitations.  The bochs drm
> was a fbdev driver initially.  Never merged.  Got rewritten as drm
> driver and that was merged instead.  In 2013, almost a decade ago.
>
> And, yes, it very well might be that drm misses some piece here and
> there for specific hardware, such as fbdev emulation not supporting
> rgb332.  But I fully agree with Thomas here:  Improving drm is probably
> a much better way to spend your time.  drm is where the development
> happens.  fbdev is only kept alive.

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).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Fri, Jan 21, 2022 at 9:46 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > What I still don't understand: why are you so keen on maintaining an
> > interface that only serves the console? Nothing else uses fbdev these days.
> > Why not improve DRM/userspace to the point where it fits your requirements?
> > Long-term, the latter would make a lot more sense.
>
> And note that it is *much* easier to write drm drivers these days.
> We got alot of helpers, we got generic fbdev emulation and more.
>
> If you are curious just compare the initial commit of the bochs drm
> driver with the current code.  Initially the driver had to manage ttm
> and fbdev and whatnot else.  These days writing a (non-accelerated) drm
> driver is basically some boilerplate picking the helpers which work best
> for your hardware, the code to actually program the hardware and that's
> it.
>
> The "new drivers should be drm" policy exists for years already btw,
> exactly because of the unfixable fbdev API limitations.  The bochs drm
> was a fbdev driver initially.  Never merged.  Got rewritten as drm
> driver and that was merged instead.  In 2013, almost a decade ago.
>
> And, yes, it very well might be that drm misses some piece here and
> there for specific hardware, such as fbdev emulation not supporting
> rgb332.  But I fully agree with Thomas here:  Improving drm is probably
> a much better way to spend your time.  drm is where the development
> happens.  fbdev is only kept alive.

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).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.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.

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

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.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.

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

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 24, 2022 at 7:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.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

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 24, 2022 at 7:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.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

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2224 bytes --]

Hi

Am 24.01.22 um 19:38 schrieb Geert Uytterhoeven:
> Hi Daniel,
> 
> On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.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.
> 
> 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...

That sounds pretty cool.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2224 bytes --]

Hi

Am 24.01.22 um 19:38 schrieb Geert Uytterhoeven:
> Hi Daniel,
> 
> On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.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.
> 
> 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...

That sounds pretty cool.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 07:29, Gerd Hoffmann wrote:
>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
>> currently unaccelerated and bound to Truecolour modes only,
>
> Yes.  Adding support for formats beside argb8888 to the drm fbcon
> emulation shouldn't be that much of a problem though.

Really? Assuming a graphic card which runs with only 256 colors framebuffer
is easily supported by DRM, and you can use fbcon without using lots of memcpy()?

> Acceleration is harder.  The scroll acceleration had issues nobody
> addressed for years, and on modern hardware it is simply not used, which
> is probably the reason nobody stepped up fixing things and it ended up
> being dropped.

The DRM layer doesn't use scroll acceleration.
More than 30 other existing fbdev drivers use it.

> Bringing it back is much more work than just reverting the commits removing it.

Reverting those commits have no effect on DRM's usage of fbcon.
But reverting those commits bring back scroll acceleration for all others.
I'm trying to find out which patches did apparently fixed such issues
for the REDRAW case. If you have a pointer it would be helpful.

> Also note that using a shadow framebuffer allows to decouple fbcon
> updates and scanout framebuffer updates.  Can be used to speed up
> things without depending on the 2d blitter.

Not on older hardware.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 07:29, Gerd Hoffmann wrote:
>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
>> currently unaccelerated and bound to Truecolour modes only,
>
> Yes.  Adding support for formats beside argb8888 to the drm fbcon
> emulation shouldn't be that much of a problem though.

Really? Assuming a graphic card which runs with only 256 colors framebuffer
is easily supported by DRM, and you can use fbcon without using lots of memcpy()?

> Acceleration is harder.  The scroll acceleration had issues nobody
> addressed for years, and on modern hardware it is simply not used, which
> is probably the reason nobody stepped up fixing things and it ended up
> being dropped.

The DRM layer doesn't use scroll acceleration.
More than 30 other existing fbdev drivers use it.

> Bringing it back is much more work than just reverting the commits removing it.

Reverting those commits have no effect on DRM's usage of fbcon.
But reverting those commits bring back scroll acceleration for all others.
I'm trying to find out which patches did apparently fixed such issues
for the REDRAW case. If you have a pointer it would be helpful.

> Also note that using a shadow framebuffer allows to decouple fbcon
> updates and scanout framebuffer updates.  Can be used to speed up
> things without depending on the 2d blitter.

Not on older hardware.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
> On 1/18/22 07:29, Gerd Hoffmann wrote:
> >> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
> >> currently unaccelerated and bound to Truecolour modes only,
> >
> > Yes.  Adding support for formats beside argb8888 to the drm fbcon
> > emulation shouldn't be that much of a problem though.
> 
> Really? Assuming a graphic card which runs with only 256 colors framebuffer
> is easily supported by DRM, and you can use fbcon without using lots of memcpy()?

Driver: programming a fixed color cube palette, then use RGB332.

fbcon/fbdev emulation: RGB332 support must be added I think.  But both
argb888 and rgb565 are supported today, so it should not be hard to find
the places where you have to add some code to handle RGB332 too.

> > Acceleration is harder.  The scroll acceleration had issues nobody
> > addressed for years, and on modern hardware it is simply not used, which
> > is probably the reason nobody stepped up fixing things and it ended up
> > being dropped.
> 
> The DRM layer doesn't use scroll acceleration.
> More than 30 other existing fbdev drivers use it.

Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
hardware simply has no classic blitter any more.  Which is a problem
when it comes to keeping scroll acceleration alive, it is already a very
niche use case and it will only become worse ...

> > Bringing it back is much more work than just reverting the commits removing it.
> 
> Reverting those commits have no effect on DRM's usage of fbcon.
> But reverting those commits bring back scroll acceleration for all others.
> I'm trying to find out which patches did apparently fixed such issues
> for the REDRAW case. If you have a pointer it would be helpful.

IIRC the code had a bunch of races and syzkaller flagged problems.
I didn't follow very closely though.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
> On 1/18/22 07:29, Gerd Hoffmann wrote:
> >> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
> >> currently unaccelerated and bound to Truecolour modes only,
> >
> > Yes.  Adding support for formats beside argb8888 to the drm fbcon
> > emulation shouldn't be that much of a problem though.
> 
> Really? Assuming a graphic card which runs with only 256 colors framebuffer
> is easily supported by DRM, and you can use fbcon without using lots of memcpy()?

Driver: programming a fixed color cube palette, then use RGB332.

fbcon/fbdev emulation: RGB332 support must be added I think.  But both
argb888 and rgb565 are supported today, so it should not be hard to find
the places where you have to add some code to handle RGB332 too.

> > Acceleration is harder.  The scroll acceleration had issues nobody
> > addressed for years, and on modern hardware it is simply not used, which
> > is probably the reason nobody stepped up fixing things and it ended up
> > being dropped.
> 
> The DRM layer doesn't use scroll acceleration.
> More than 30 other existing fbdev drivers use it.

Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
hardware simply has no classic blitter any more.  Which is a problem
when it comes to keeping scroll acceleration alive, it is already a very
niche use case and it will only become worse ...

> > Bringing it back is much more work than just reverting the commits removing it.
> 
> Reverting those commits have no effect on DRM's usage of fbcon.
> But reverting those commits bring back scroll acceleration for all others.
> I'm trying to find out which patches did apparently fixed such issues
> for the REDRAW case. If you have a pointer it would be helpful.

IIRC the code had a bunch of races and syzkaller flagged problems.
I didn't follow very closely though.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 10:16, Gerd Hoffmann wrote:
> On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
>> On 1/18/22 07:29, Gerd Hoffmann wrote:
>>>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
>>>> currently unaccelerated and bound to Truecolour modes only,
>>>
>>> Yes.  Adding support for formats beside argb8888 to the drm fbcon
>>> emulation shouldn't be that much of a problem though.
>>
>> Really? Assuming a graphic card which runs with only 256 colors framebuffer
>> is easily supported by DRM, and you can use fbcon without using lots of memcpy()?
>
> Driver: programming a fixed color cube palette, then use RGB332.
>
> fbcon/fbdev emulation: RGB332 support must be added I think.  But both
> argb888 and rgb565 are supported today, so it should not be hard to find
> the places where you have to add some code to handle RGB332 too.

I'd expect that that framework is provided by DRM developers if there is the wish
to get rid of old fbdev and transition existing drivers over to use DRM.

>>> Acceleration is harder.  The scroll acceleration had issues nobody
>>> addressed for years, and on modern hardware it is simply not used, which
>>> is probably the reason nobody stepped up fixing things and it ended up
>>> being dropped.
>>
>> The DRM layer doesn't use scroll acceleration.
>> More than 30 other existing fbdev drivers use it.
>
> Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
> hardware simply has no classic blitter any more.  Which is a problem
> when it comes to keeping scroll acceleration alive, it is already a very
> niche use case and it will only become worse ...

For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today
with the arguments mentioned multiple times).
But the patches broke existing fbdev acceleration which is available by
the fbdev drivers. That's a big regression from point of fbdev.

>>> Bringing it back is much more work than just reverting the commits removing it.
>>
>> Reverting those commits have no effect on DRM's usage of fbcon.
>> But reverting those commits bring back scroll acceleration for all others.
>> I'm trying to find out which patches did apparently fixed such issues
>> for the REDRAW case. If you have a pointer it would be helpful.
>
> IIRC the code had a bunch of races and syzkaller flagged problems.
> I didn't follow very closely though.

That's sad.
Nevertheless I wonder if the changes which were apparently done for
the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues
for SCROLL_MOVE.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 10:16, Gerd Hoffmann wrote:
> On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
>> On 1/18/22 07:29, Gerd Hoffmann wrote:
>>>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
>>>> currently unaccelerated and bound to Truecolour modes only,
>>>
>>> Yes.  Adding support for formats beside argb8888 to the drm fbcon
>>> emulation shouldn't be that much of a problem though.
>>
>> Really? Assuming a graphic card which runs with only 256 colors framebuffer
>> is easily supported by DRM, and you can use fbcon without using lots of memcpy()?
>
> Driver: programming a fixed color cube palette, then use RGB332.
>
> fbcon/fbdev emulation: RGB332 support must be added I think.  But both
> argb888 and rgb565 are supported today, so it should not be hard to find
> the places where you have to add some code to handle RGB332 too.

I'd expect that that framework is provided by DRM developers if there is the wish
to get rid of old fbdev and transition existing drivers over to use DRM.

>>> Acceleration is harder.  The scroll acceleration had issues nobody
>>> addressed for years, and on modern hardware it is simply not used, which
>>> is probably the reason nobody stepped up fixing things and it ended up
>>> being dropped.
>>
>> The DRM layer doesn't use scroll acceleration.
>> More than 30 other existing fbdev drivers use it.
>
> Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
> hardware simply has no classic blitter any more.  Which is a problem
> when it comes to keeping scroll acceleration alive, it is already a very
> niche use case and it will only become worse ...

For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today
with the arguments mentioned multiple times).
But the patches broke existing fbdev acceleration which is available by
the fbdev drivers. That's a big regression from point of fbdev.

>>> Bringing it back is much more work than just reverting the commits removing it.
>>
>> Reverting those commits have no effect on DRM's usage of fbcon.
>> But reverting those commits bring back scroll acceleration for all others.
>> I'm trying to find out which patches did apparently fixed such issues
>> for the REDRAW case. If you have a pointer it would be helpful.
>
> IIRC the code had a bunch of races and syzkaller flagged problems.
> I didn't follow very closely though.

That's sad.
Nevertheless I wonder if the changes which were apparently done for
the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues
for SCROLL_MOVE.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 11:13, Helge Deller wrote:
> On 1/18/22 10:16, Gerd Hoffmann wrote:
>> On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
>>> On 1/18/22 07:29, Gerd Hoffmann wrote:
>>>>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
>>>>> currently unaccelerated and bound to Truecolour modes only,
>>>>
>>>> Yes.  Adding support for formats beside argb8888 to the drm fbcon
>>>> emulation shouldn't be that much of a problem though.
>>>
>>> Really? Assuming a graphic card which runs with only 256 colors framebuffer
>>> is easily supported by DRM, and you can use fbcon without using lots of memcpy()?
>>
>> Driver: programming a fixed color cube palette, then use RGB332.
>>
>> fbcon/fbdev emulation: RGB332 support must be added I think.  But both
>> argb888 and rgb565 are supported today, so it should not be hard to find
>> the places where you have to add some code to handle RGB332 too.
>
> I'd expect that that framework is provided by DRM developers if there is the wish
> to get rid of old fbdev and transition existing drivers over to use DRM.
>
>>>> Acceleration is harder.  The scroll acceleration had issues nobody
>>>> addressed for years, and on modern hardware it is simply not used, which
>>>> is probably the reason nobody stepped up fixing things and it ended up
>>>> being dropped.
>>>
>>> The DRM layer doesn't use scroll acceleration.
>>> More than 30 other existing fbdev drivers use it.
>>
>> Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
>> hardware simply has no classic blitter any more.  Which is a problem
>> when it comes to keeping scroll acceleration alive, it is already a very
>> niche use case and it will only become worse ...
>
> For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today
> with the arguments mentioned multiple times).
> But the patches broke existing fbdev acceleration which is available by
> the fbdev drivers. That's a big regression from point of fbdev.
>
>>>> Bringing it back is much more work than just reverting the commits removing it.
>>>
>>> Reverting those commits have no effect on DRM's usage of fbcon.
>>> But reverting those commits bring back scroll acceleration for all others.
>>> I'm trying to find out which patches did apparently fixed such issues
>>> for the REDRAW case. If you have a pointer it would be helpful.
>>
>> IIRC the code had a bunch of races and syzkaller flagged problems.
>> I didn't follow very closely though.
>
> That's sad.
> Nevertheless I wonder if the changes which were apparently done for
> the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues
> for SCROLL_MOVE.

I've just looked through all patches in drivers/video which were tagged
with syzbot or syzkaller back to year 2005. The vast majority fixed the
reported issues on a higher level, e.g. when screen is to be resized,
or when font size is to be changed. The few ones which touched driver
code fixed a real driver bug, e.g. by adding a check.

NONE of those patches touched either the SCROLL_MOVE or the SCROLL_REDRAW case.
That means, I see no reason why SCROLL_MOVE had to be ripped-out and just
SCROLL_REDRAW had to be used instead, other than simply "it's not being
used by DRM, so let's pull it out".
The patches which removed SCROLL_MOVE support simply ignored the fact
that SCROLL_MOVE is still heavily used by fbdev (non-DRM).

I don't see a reason why the two patches which removed SCROLL_MOVE
shouldn't be reverted. Or what am I missing?

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 11:13, Helge Deller wrote:
> On 1/18/22 10:16, Gerd Hoffmann wrote:
>> On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
>>> On 1/18/22 07:29, Gerd Hoffmann wrote:
>>>>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
>>>>> currently unaccelerated and bound to Truecolour modes only,
>>>>
>>>> Yes.  Adding support for formats beside argb8888 to the drm fbcon
>>>> emulation shouldn't be that much of a problem though.
>>>
>>> Really? Assuming a graphic card which runs with only 256 colors framebuffer
>>> is easily supported by DRM, and you can use fbcon without using lots of memcpy()?
>>
>> Driver: programming a fixed color cube palette, then use RGB332.
>>
>> fbcon/fbdev emulation: RGB332 support must be added I think.  But both
>> argb888 and rgb565 are supported today, so it should not be hard to find
>> the places where you have to add some code to handle RGB332 too.
>
> I'd expect that that framework is provided by DRM developers if there is the wish
> to get rid of old fbdev and transition existing drivers over to use DRM.
>
>>>> Acceleration is harder.  The scroll acceleration had issues nobody
>>>> addressed for years, and on modern hardware it is simply not used, which
>>>> is probably the reason nobody stepped up fixing things and it ended up
>>>> being dropped.
>>>
>>> The DRM layer doesn't use scroll acceleration.
>>> More than 30 other existing fbdev drivers use it.
>>
>> Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
>> hardware simply has no classic blitter any more.  Which is a problem
>> when it comes to keeping scroll acceleration alive, it is already a very
>> niche use case and it will only become worse ...
>
> For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today
> with the arguments mentioned multiple times).
> But the patches broke existing fbdev acceleration which is available by
> the fbdev drivers. That's a big regression from point of fbdev.
>
>>>> Bringing it back is much more work than just reverting the commits removing it.
>>>
>>> Reverting those commits have no effect on DRM's usage of fbcon.
>>> But reverting those commits bring back scroll acceleration for all others.
>>> I'm trying to find out which patches did apparently fixed such issues
>>> for the REDRAW case. If you have a pointer it would be helpful.
>>
>> IIRC the code had a bunch of races and syzkaller flagged problems.
>> I didn't follow very closely though.
>
> That's sad.
> Nevertheless I wonder if the changes which were apparently done for
> the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues
> for SCROLL_MOVE.

I've just looked through all patches in drivers/video which were tagged
with syzbot or syzkaller back to year 2005. The vast majority fixed the
reported issues on a higher level, e.g. when screen is to be resized,
or when font size is to be changed. The few ones which touched driver
code fixed a real driver bug, e.g. by adding a check.

NONE of those patches touched either the SCROLL_MOVE or the SCROLL_REDRAW case.
That means, I see no reason why SCROLL_MOVE had to be ripped-out and just
SCROLL_REDRAW had to be used instead, other than simply "it's not being
used by DRM, so let's pull it out".
The patches which removed SCROLL_MOVE support simply ignored the fact
that SCROLL_MOVE is still heavily used by fbdev (non-DRM).

I don't see a reason why the two patches which removed SCROLL_MOVE
shouldn't be reverted. Or what am I missing?

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> > fbcon/fbdev emulation: RGB332 support must be added I think.  But both
> > argb888 and rgb565 are supported today, so it should not be hard to find
> > the places where you have to add some code to handle RGB332 too.
> 
> I'd expect that that framework is provided by DRM developers if there is the wish
> to get rid of old fbdev and transition existing drivers over to use DRM.

Good luck with that.  Asking people to code up stuff they can't even
test due to lack of hardware isn't going to fly very well.

> > Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
> > hardware simply has no classic blitter any more.  Which is a problem
> > when it comes to keeping scroll acceleration alive, it is already a very
> > niche use case and it will only become worse ...
> 
> For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today
> with the arguments mentioned multiple times).
> But the patches broke existing fbdev acceleration which is available by
> the fbdev drivers. That's a big regression from point of fbdev.

Keeping it alive and working will be a tough challenge.  2d acceleration
is a thing of the past and the number of people which are able and
willing to put effort into supporting it will only decline.  It has been
a problem for a while already, basically it was dropped due to lack of
support ...

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> > fbcon/fbdev emulation: RGB332 support must be added I think.  But both
> > argb888 and rgb565 are supported today, so it should not be hard to find
> > the places where you have to add some code to handle RGB332 too.
> 
> I'd expect that that framework is provided by DRM developers if there is the wish
> to get rid of old fbdev and transition existing drivers over to use DRM.

Good luck with that.  Asking people to code up stuff they can't even
test due to lack of hardware isn't going to fly very well.

> > Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
> > hardware simply has no classic blitter any more.  Which is a problem
> > when it comes to keeping scroll acceleration alive, it is already a very
> > niche use case and it will only become worse ...
> 
> For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today
> with the arguments mentioned multiple times).
> But the patches broke existing fbdev acceleration which is available by
> the fbdev drivers. That's a big regression from point of fbdev.

Keeping it alive and working will be a tough challenge.  2d acceleration
is a thing of the past and the number of people which are able and
willing to put effort into supporting it will only decline.  It has been
a problem for a while already, basically it was dropped due to lack of
support ...

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2359 bytes --]

Hi

Am 17.01.22 um 15:47 schrieb Helge Deller:
> On 1/17/22 15:10, Geert Uytterhoeven wrote:
> [...]
>> Using an XRGB32 intermediate would kill the user experience on old
>> machines, due to both increased memory usage and copy overhead.
>>
>>> Personally, I'd much appreciate if userspace would support more of the
>>> native formats and not rely on XRGB32.
>>
>> Supporting monochrome, 16 colors, and 256 colors would be nice.
> 
>  From this conversation it seems DRM completely lacks backwards compatibility,
> including a missing 2D bitblt copy.
> Isn't that all what's needed and then migrating existing drivers would
> be easy ?

What exactly do you mean by 'backwards compatibility'? The driver API is 
different, of course. My conversion helpers can provide a starting point 
to move fbdev code into DRM drivers.

For fbdev 2d-bitblt ioctls, you can add them to DRM drivers and set up 
DRM's fbdev emulation accordingly. Some DRM drivers do/did this. To my 
knowledge, so far there's not been a use case where that provides a 
benefit over simple memcpy. For fast 2d blitting from userspace, you 
should read Daniel's comment at [1]. tl;dr: a generic solution is 
non-trivial.

Best regards
Thomas

[1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html

> 
> Helge
> 
> 
>>>> This not only to support "old" hardware, but also modern small OLED
>>>> and e-ink displays.
>>>
>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>>> least.
>>
>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
>> to convert from truecolor to monochrome.  I guess that would work,
>> as this is a slow e-ink display.  Have fun as a text console ;-)
>>
>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>>                                  -- Linus Torvalds
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2359 bytes --]

Hi

Am 17.01.22 um 15:47 schrieb Helge Deller:
> On 1/17/22 15:10, Geert Uytterhoeven wrote:
> [...]
>> Using an XRGB32 intermediate would kill the user experience on old
>> machines, due to both increased memory usage and copy overhead.
>>
>>> Personally, I'd much appreciate if userspace would support more of the
>>> native formats and not rely on XRGB32.
>>
>> Supporting monochrome, 16 colors, and 256 colors would be nice.
> 
>  From this conversation it seems DRM completely lacks backwards compatibility,
> including a missing 2D bitblt copy.
> Isn't that all what's needed and then migrating existing drivers would
> be easy ?

What exactly do you mean by 'backwards compatibility'? The driver API is 
different, of course. My conversion helpers can provide a starting point 
to move fbdev code into DRM drivers.

For fbdev 2d-bitblt ioctls, you can add them to DRM drivers and set up 
DRM's fbdev emulation accordingly. Some DRM drivers do/did this. To my 
knowledge, so far there's not been a use case where that provides a 
benefit over simple memcpy. For fast 2d blitting from userspace, you 
should read Daniel's comment at [1]. tl;dr: a generic solution is 
non-trivial.

Best regards
Thomas

[1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html

> 
> Helge
> 
> 
>>>> This not only to support "old" hardware, but also modern small OLED
>>>> and e-ink displays.
>>>
>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>>> least.
>>
>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
>> to convert from truecolor to monochrome.  I guess that would work,
>> as this is a slow e-ink display.  Have fun as a text console ;-)
>>
>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>>                                  -- Linus Torvalds
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hi Thomas,

On 1/17/22 16:05, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.22 um 15:47 schrieb Helge Deller:
>> On 1/17/22 15:10, Geert Uytterhoeven wrote:
>> [...]
>>> Using an XRGB32 intermediate would kill the user experience on old
>>> machines, due to both increased memory usage and copy overhead.
>>>
>>>> Personally, I'd much appreciate if userspace would support more of the
>>>> native formats and not rely on XRGB32.
>>>
>>> Supporting monochrome, 16 colors, and 256 colors would be nice.
>>
>>  From this conversation it seems DRM completely lacks backwards compatibility,
>> including a missing 2D bitblt copy.
>> Isn't that all what's needed and then migrating existing drivers would
>> be easy ?
>
> What exactly do you mean by 'backwards compatibility'?

DRM to provide possibility to run (in at least a few) of the bitmap formats
mentioned above.

> The driver API is different, of course.

Sure.
I would think of a defined set how to activate a special graphics output.
And a function to do on-screen 2D bitblt to move contents (for usage of
fbcon emulation).

> My conversion helpers can provide a starting point to move fbdev code
> into DRM drivers.
I need to look into this.

> For fbdev 2d-bitblt ioctls,

I'm not talking about 2d bitblt "IOCTLS". I'm talking about fbcon utilizing
2D graphic card bitblt to move on-screen contents to speed up a text console.
E.g. text upwards scrolling.

> you can add them to DRM drivers and set
> up DRM's fbdev emulation accordingly. Some DRM drivers do/did this.

> To my knowledge, so far there's not been a use case where that
> provides a benefit over simple memcpy.

It's a huge difference on older machines with slower busses for example.
So, for text console emulation, moving windows ... it's important.

> For fast 2d blitting from userspace, you should read Daniel's comment
> at [1]. tl;dr: a generic solution is non-trivial.
Probably. I think fbdev doesn't provide that functionality either today
(at least I think so) - so that's probably not a focus (and not relevant
regading the "backwards compatibility" I mentioned).

Helge


> Best regards
> Thomas
>
> [1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html
>
>>
>> Helge
>>
>>
>>>>> This not only to support "old" hardware, but also modern small OLED
>>>>> and e-ink displays.
>>>>
>>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>>>> least.
>>>
>>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
>>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
>>> to convert from truecolor to monochrome.  I guess that would work,
>>> as this is a slow e-ink display.  Have fun as a text console ;-)
>>>
>>> Gr{oetje,eeting}s,
>>>
>>>                          Geert
>>>
>>> --
>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>>
>>> In personal conversations with technical people, I call myself a hacker. But
>>> when I'm talking to journalists I just say "programmer" or something like that.
>>>                                  -- Linus Torvalds
>>>
>>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hi Thomas,

On 1/17/22 16:05, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.22 um 15:47 schrieb Helge Deller:
>> On 1/17/22 15:10, Geert Uytterhoeven wrote:
>> [...]
>>> Using an XRGB32 intermediate would kill the user experience on old
>>> machines, due to both increased memory usage and copy overhead.
>>>
>>>> Personally, I'd much appreciate if userspace would support more of the
>>>> native formats and not rely on XRGB32.
>>>
>>> Supporting monochrome, 16 colors, and 256 colors would be nice.
>>
>>  From this conversation it seems DRM completely lacks backwards compatibility,
>> including a missing 2D bitblt copy.
>> Isn't that all what's needed and then migrating existing drivers would
>> be easy ?
>
> What exactly do you mean by 'backwards compatibility'?

DRM to provide possibility to run (in at least a few) of the bitmap formats
mentioned above.

> The driver API is different, of course.

Sure.
I would think of a defined set how to activate a special graphics output.
And a function to do on-screen 2D bitblt to move contents (for usage of
fbcon emulation).

> My conversion helpers can provide a starting point to move fbdev code
> into DRM drivers.
I need to look into this.

> For fbdev 2d-bitblt ioctls,

I'm not talking about 2d bitblt "IOCTLS". I'm talking about fbcon utilizing
2D graphic card bitblt to move on-screen contents to speed up a text console.
E.g. text upwards scrolling.

> you can add them to DRM drivers and set
> up DRM's fbdev emulation accordingly. Some DRM drivers do/did this.

> To my knowledge, so far there's not been a use case where that
> provides a benefit over simple memcpy.

It's a huge difference on older machines with slower busses for example.
So, for text console emulation, moving windows ... it's important.

> For fast 2d blitting from userspace, you should read Daniel's comment
> at [1]. tl;dr: a generic solution is non-trivial.
Probably. I think fbdev doesn't provide that functionality either today
(at least I think so) - so that's probably not a focus (and not relevant
regading the "backwards compatibility" I mentioned).

Helge


> Best regards
> Thomas
>
> [1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html
>
>>
>> Helge
>>
>>
>>>>> This not only to support "old" hardware, but also modern small OLED
>>>>> and e-ink displays.
>>>>
>>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at
>>>> least.
>>>
>>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
>>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
>>> to convert from truecolor to monochrome.  I guess that would work,
>>> as this is a slow e-ink display.  Have fun as a text console ;-)
>>>
>>> Gr{oetje,eeting}s,
>>>
>>>                          Geert
>>>
>>> --
>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>>
>>> In personal conversations with technical people, I call myself a hacker. But
>>> when I'm talking to journalists I just say "programmer" or something like that.
>>>                                  -- Linus Torvalds
>>>
>>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]

Hi

Am 17.01.22 um 15:10 schrieb Geert Uytterhoeven:
> [...]  
> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
> to convert from truecolor to monochrome.  I guess that would work,
> as this is a slow e-ink display.  Have fun as a text console ;-)

But that's really just a question of optimization. The console is 
userspace-ish in that no one has asked for monochrome support yet. So 
it's not there. We could add it if it's ever needed.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]

Hi

Am 17.01.22 um 15:10 schrieb Geert Uytterhoeven:
> [...]  
> Which uses an DRM_FORMAT_XRGB8888 intermediate, and
> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
> to convert from truecolor to monochrome.  I guess that would work,
> as this is a slow e-ink display.  Have fun as a text console ;-)

But that's really just a question of optimization. The console is 
userspace-ish in that no one has asked for monochrome support yet. So 
it's not there. We could add it if it's ever needed.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote:
> Hi Gerd,
> 
> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> > >    I know of at least one driver which won't be able to support DRM....
> >
> > Hmm?  I seriously doubt that.  There is always the option to use a
> > shadow framebuffer, then convert from standard drm formats to whatever
> > esoteric pixel format your hardware expects.
> >
> > Been there, done that.  Have a look at the cirrus driver.  The physical
> > hardware was designed in the early 90-ies, almost 30 years ago.  These
> > days it exists in virtual form only (qemu emulates it).  Thanks to the
> > drm driver it runs wayland just fine even though it has a bunch of
> > constrains dictated by the hardware design.
> 
> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> modes only.  The Cirrus fbdev driver also supports mochrome and 256
> color modes.
> 
> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.

Adding that to the cirrus driver shouldn't be hard.  I'm wondering
whenever there are any userspace apps which would actually use that
though.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote:
> Hi Gerd,
> 
> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> > >    I know of at least one driver which won't be able to support DRM....
> >
> > Hmm?  I seriously doubt that.  There is always the option to use a
> > shadow framebuffer, then convert from standard drm formats to whatever
> > esoteric pixel format your hardware expects.
> >
> > Been there, done that.  Have a look at the cirrus driver.  The physical
> > hardware was designed in the early 90-ies, almost 30 years ago.  These
> > days it exists in virtual form only (qemu emulates it).  Thanks to the
> > drm driver it runs wayland just fine even though it has a bunch of
> > constrains dictated by the hardware design.
> 
> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
> modes only.  The Cirrus fbdev driver also supports mochrome and 256
> color modes.
> 
> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.

Adding that to the cirrus driver shouldn't be hard.  I'm wondering
whenever there are any userspace apps which would actually use that
though.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 07:11, Gerd Hoffmann wrote:
> On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote:
>> Hi Gerd,
>>
>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>>    I know of at least one driver which won't be able to support DRM....
>>>
>>> Hmm?  I seriously doubt that.  There is always the option to use a
>>> shadow framebuffer, then convert from standard drm formats to whatever
>>> esoteric pixel format your hardware expects.
>>>
>>> Been there, done that.  Have a look at the cirrus driver.  The physical
>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>>> drm driver it runs wayland just fine even though it has a bunch of
>>> constrains dictated by the hardware design.
>>
>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
>> color modes.
>>
>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.
>
> Adding that to the cirrus driver shouldn't be hard.  I'm wondering
> whenever there are any userspace apps which would actually use that
> though.

The discussion is not about userspace apps.

It's about the case, that if existing fbdev drivers should be converted to
DRM, then they are currently required to run in TrueColor. Some of those cards/drivers
don't support TrueColor (which is problem #1), and even if they do, then
only with their existing 2D bitblt acceleration they are somewhat performance-wise
useable as framebuffer console (problem #2).

So, if DRM would natively support other formats, then it's not hard to
convert them to DRM.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 07:11, Gerd Hoffmann wrote:
> On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote:
>> Hi Gerd,
>>
>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>>    I know of at least one driver which won't be able to support DRM....
>>>
>>> Hmm?  I seriously doubt that.  There is always the option to use a
>>> shadow framebuffer, then convert from standard drm formats to whatever
>>> esoteric pixel format your hardware expects.
>>>
>>> Been there, done that.  Have a look at the cirrus driver.  The physical
>>> hardware was designed in the early 90-ies, almost 30 years ago.  These
>>> days it exists in virtual form only (qemu emulates it).  Thanks to the
>>> drm driver it runs wayland just fine even though it has a bunch of
>>> constrains dictated by the hardware design.
>>
>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
>> modes only.  The Cirrus fbdev driver also supports mochrome and 256
>> color modes.
>>
>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.
>
> Adding that to the cirrus driver shouldn't be hard.  I'm wondering
> whenever there are any userspace apps which would actually use that
> though.

The discussion is not about userspace apps.

It's about the case, that if existing fbdev drivers should be converted to
DRM, then they are currently required to run in TrueColor. Some of those cards/drivers
don't support TrueColor (which is problem #1), and even if they do, then
only with their existing 2D bitblt acceleration they are somewhat performance-wise
useable as framebuffer console (problem #2).

So, if DRM would natively support other formats, then it's not hard to
convert them to DRM.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>
> Hello Daniel,
>
> On 1/17/22 11:02, Daniel Vetter wrote:
> > Hi Helge
> >
> > On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
> >>
> >> The fbdev layer is orphaned, but seems to need some care.
> >> So I'd like to step up as new maintainer.
> >>
> >> Signed-off-by: Helge Deller <deller@gmx.de>
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 5d0cd537803a..ce47dbc467cc 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
> >>  F:     arch/x86/math-emu/
> >>
> >>  FRAMEBUFFER LAYER
> >> -L:     dri-devel@lists.freedesktop.org
> >> +M:     Helge Deller <deller@gmx.de>
> >>  L:     linux-fbdev@vger.kernel.org
> >> -S:     Orphan
> >
> > Maybe don't rush maintainer changes in over the w/e without even bothering
> > to get any input from the people who've been maintaining it before.
> >
> > Because the status isn't entirely correct, fbdev core code and fbcon and
> > all that has been maintained, but in bugfixes only mode. And there's very
> > solid&important reasons to keep merging these patches through a drm tree,
> > because that's where all the driver development happens, and hence also
> > all the testing (e.g. the drm test suite has some fbdev tests - the only
> > automated ones that exist to my knowledge - and we run them in CI). So
> > moving that into an obscure new tree which isn't even in linux-next yet is
> > no good at all.
> >
> > Now fbdev driver bugfixes is indeed practically orphaned and I very much
> > welcome anyone stepping up for that, but the simplest approach there would
> > be to just get drm-misc commit rights and push the oddball bugfix in there
> > directly. But also if you want to do your own pull requests to Linus for
> > that I don't care and there's really no interference I think, so
> > whatever floats.
> >
> > But any code that is relevant for drm drivers really needs to go in through
> > drm trees, nothing else makes much sense.
> >
> > I guess you're first action as newly minted fbdev maintainer is going to be to
> > clean up the confusion you just created.
>
> Most of my machines depend on a working fbdev layer since drm isn't (and probably
> -due to technical requirements of DRM- won't be) available for those.
> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>
> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
> For me it's really not important to drive any patches through a seperate tree, so
> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
> adding my tree to for-next was on my todo list...)
>
> What's important for me though is, to keep fbdev actively maintained, which means:
> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,

Yeah it'd be great if we have that, for a while Bart took care of
these, but had to step down again. drm-misc is maintained with the dim
scrip suite, which comes with docs and bash completion and everything.
Good starting pointer is here:

https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html

Process for getting commit rights is documented here:

https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc

But there's a pile more. I think once we've set that up and got it
going we can look at the bigger items. Some of them are fairly
low-hanging fruit, but the past 5+ years absolutely no one bothered to
step up and sort them out. Other problem areas in fbdev are extremely
hard to fix properly, without only doing minimal security-fixes only
support, so fair warning there. I think a good starting point would be
to read the patches and discussions for some of the things you've
reverted in your tree.

Anyway I hope this gets you started, and hopefully after a minor
detour: Welcome to dri-devel, we're happy to take any help we can get,
there's lots to do!

Cheers, Daniel

> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>    I know of at least one driver which won't be able to support DRM....
>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>    either when run on native hardware or in an emulator.
> d) not break DRM development
>
> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> understand where the actual problems were and what's necessary to fix them.
>
> Helge
>
> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>
> Hello Daniel,
>
> On 1/17/22 11:02, Daniel Vetter wrote:
> > Hi Helge
> >
> > On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
> >>
> >> The fbdev layer is orphaned, but seems to need some care.
> >> So I'd like to step up as new maintainer.
> >>
> >> Signed-off-by: Helge Deller <deller@gmx.de>
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 5d0cd537803a..ce47dbc467cc 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
> >>  F:     arch/x86/math-emu/
> >>
> >>  FRAMEBUFFER LAYER
> >> -L:     dri-devel@lists.freedesktop.org
> >> +M:     Helge Deller <deller@gmx.de>
> >>  L:     linux-fbdev@vger.kernel.org
> >> -S:     Orphan
> >
> > Maybe don't rush maintainer changes in over the w/e without even bothering
> > to get any input from the people who've been maintaining it before.
> >
> > Because the status isn't entirely correct, fbdev core code and fbcon and
> > all that has been maintained, but in bugfixes only mode. And there's very
> > solid&important reasons to keep merging these patches through a drm tree,
> > because that's where all the driver development happens, and hence also
> > all the testing (e.g. the drm test suite has some fbdev tests - the only
> > automated ones that exist to my knowledge - and we run them in CI). So
> > moving that into an obscure new tree which isn't even in linux-next yet is
> > no good at all.
> >
> > Now fbdev driver bugfixes is indeed practically orphaned and I very much
> > welcome anyone stepping up for that, but the simplest approach there would
> > be to just get drm-misc commit rights and push the oddball bugfix in there
> > directly. But also if you want to do your own pull requests to Linus for
> > that I don't care and there's really no interference I think, so
> > whatever floats.
> >
> > But any code that is relevant for drm drivers really needs to go in through
> > drm trees, nothing else makes much sense.
> >
> > I guess you're first action as newly minted fbdev maintainer is going to be to
> > clean up the confusion you just created.
>
> Most of my machines depend on a working fbdev layer since drm isn't (and probably
> -due to technical requirements of DRM- won't be) available for those.
> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>
> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
> For me it's really not important to drive any patches through a seperate tree, so
> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
> adding my tree to for-next was on my todo list...)
>
> What's important for me though is, to keep fbdev actively maintained, which means:
> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,

Yeah it'd be great if we have that, for a while Bart took care of
these, but had to step down again. drm-misc is maintained with the dim
scrip suite, which comes with docs and bash completion and everything.
Good starting pointer is here:

https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html

Process for getting commit rights is documented here:

https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc

But there's a pile more. I think once we've set that up and got it
going we can look at the bigger items. Some of them are fairly
low-hanging fruit, but the past 5+ years absolutely no one bothered to
step up and sort them out. Other problem areas in fbdev are extremely
hard to fix properly, without only doing minimal security-fixes only
support, so fair warning there. I think a good starting point would be
to read the patches and discussions for some of the things you've
reverted in your tree.

Anyway I hope this gets you started, and hopefully after a minor
detour: Welcome to dri-devel, we're happy to take any help we can get,
there's lots to do!

Cheers, Daniel

> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>    I know of at least one driver which won't be able to support DRM....
>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>    either when run on native hardware or in an emulator.
> d) not break DRM development
>
> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> understand where the actual problems were and what's necessary to fix them.
>
> Helge
>
> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 16:00, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>>
>> Hello Daniel,
>>
>> On 1/17/22 11:02, Daniel Vetter wrote:
>>> Hi Helge
>>>
>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> The fbdev layer is orphaned, but seems to need some care.
>>>> So I'd like to step up as new maintainer.
>>>>
>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 5d0cd537803a..ce47dbc467cc 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>>  F:     arch/x86/math-emu/
>>>>
>>>>  FRAMEBUFFER LAYER
>>>> -L:     dri-devel@lists.freedesktop.org
>>>> +M:     Helge Deller <deller@gmx.de>
>>>>  L:     linux-fbdev@vger.kernel.org
>>>> -S:     Orphan
>>>
>>> Maybe don't rush maintainer changes in over the w/e without even bothering
>>> to get any input from the people who've been maintaining it before.
>>>
>>> Because the status isn't entirely correct, fbdev core code and fbcon and
>>> all that has been maintained, but in bugfixes only mode. And there's very
>>> solid&important reasons to keep merging these patches through a drm tree,
>>> because that's where all the driver development happens, and hence also
>>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>>> automated ones that exist to my knowledge - and we run them in CI). So
>>> moving that into an obscure new tree which isn't even in linux-next yet is
>>> no good at all.
>>>
>>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>>> welcome anyone stepping up for that, but the simplest approach there would
>>> be to just get drm-misc commit rights and push the oddball bugfix in there
>>> directly. But also if you want to do your own pull requests to Linus for
>>> that I don't care and there's really no interference I think, so
>>> whatever floats.
>>>
>>> But any code that is relevant for drm drivers really needs to go in through
>>> drm trees, nothing else makes much sense.
>>>
>>> I guess you're first action as newly minted fbdev maintainer is going to be to
>>> clean up the confusion you just created.
>>
>> Most of my machines depend on a working fbdev layer since drm isn't (and probably
>> -due to technical requirements of DRM- won't be) available for those.
>> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>>
>> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
>> For me it's really not important to drive any patches through a seperate tree, so
>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
>> adding my tree to for-next was on my todo list...)
>>
>> What's important for me though is, to keep fbdev actively maintained, which means:
>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
>
> Yeah it'd be great if we have that, for a while Bart took care of
> these, but had to step down again. drm-misc is maintained with the dim
> scrip suite, which comes with docs and bash completion and everything.
> Good starting pointer is here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>
> Process for getting commit rights is documented here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
>
> But there's a pile more. I think once we've set that up and got it
> going we can look at the bigger items. Some of them are fairly
> low-hanging fruit, but the past 5+ years absolutely no one bothered to
> step up and sort them out. Other problem areas in fbdev are extremely
> hard to fix properly, without only doing minimal security-fixes only
> support, so fair warning there. I think a good starting point would be
> to read the patches and discussions for some of the things you've
> reverted in your tree.
>
> Anyway I hope this gets you started, and hopefully after a minor
> detour: Welcome to dri-devel, we're happy to take any help we can get,
> there's lots to do!
>

Hello Daniel,

you somehow missed to answer my main topics below...:

>
>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>    I know of at least one driver which won't be able to support DRM....
>>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>    either when run on native hardware or in an emulator.
>> d) not break DRM development
>>
>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>> understand where the actual problems were and what's necessary to fix them.
>>
>> Helge
>>
>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 16:00, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>>
>> Hello Daniel,
>>
>> On 1/17/22 11:02, Daniel Vetter wrote:
>>> Hi Helge
>>>
>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> The fbdev layer is orphaned, but seems to need some care.
>>>> So I'd like to step up as new maintainer.
>>>>
>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 5d0cd537803a..ce47dbc467cc 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>>  F:     arch/x86/math-emu/
>>>>
>>>>  FRAMEBUFFER LAYER
>>>> -L:     dri-devel@lists.freedesktop.org
>>>> +M:     Helge Deller <deller@gmx.de>
>>>>  L:     linux-fbdev@vger.kernel.org
>>>> -S:     Orphan
>>>
>>> Maybe don't rush maintainer changes in over the w/e without even bothering
>>> to get any input from the people who've been maintaining it before.
>>>
>>> Because the status isn't entirely correct, fbdev core code and fbcon and
>>> all that has been maintained, but in bugfixes only mode. And there's very
>>> solid&important reasons to keep merging these patches through a drm tree,
>>> because that's where all the driver development happens, and hence also
>>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>>> automated ones that exist to my knowledge - and we run them in CI). So
>>> moving that into an obscure new tree which isn't even in linux-next yet is
>>> no good at all.
>>>
>>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>>> welcome anyone stepping up for that, but the simplest approach there would
>>> be to just get drm-misc commit rights and push the oddball bugfix in there
>>> directly. But also if you want to do your own pull requests to Linus for
>>> that I don't care and there's really no interference I think, so
>>> whatever floats.
>>>
>>> But any code that is relevant for drm drivers really needs to go in through
>>> drm trees, nothing else makes much sense.
>>>
>>> I guess you're first action as newly minted fbdev maintainer is going to be to
>>> clean up the confusion you just created.
>>
>> Most of my machines depend on a working fbdev layer since drm isn't (and probably
>> -due to technical requirements of DRM- won't be) available for those.
>> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>>
>> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
>> For me it's really not important to drive any patches through a seperate tree, so
>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
>> adding my tree to for-next was on my todo list...)
>>
>> What's important for me though is, to keep fbdev actively maintained, which means:
>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
>
> Yeah it'd be great if we have that, for a while Bart took care of
> these, but had to step down again. drm-misc is maintained with the dim
> scrip suite, which comes with docs and bash completion and everything.
> Good starting pointer is here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>
> Process for getting commit rights is documented here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
>
> But there's a pile more. I think once we've set that up and got it
> going we can look at the bigger items. Some of them are fairly
> low-hanging fruit, but the past 5+ years absolutely no one bothered to
> step up and sort them out. Other problem areas in fbdev are extremely
> hard to fix properly, without only doing minimal security-fixes only
> support, so fair warning there. I think a good starting point would be
> to read the patches and discussions for some of the things you've
> reverted in your tree.
>
> Anyway I hope this gets you started, and hopefully after a minor
> detour: Welcome to dri-devel, we're happy to take any help we can get,
> there's lots to do!
>

Hello Daniel,

you somehow missed to answer my main topics below...:

>
>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>    I know of at least one driver which won't be able to support DRM....
>>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>    either when run on native hardware or in an emulator.
>> d) not break DRM development
>>
>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>> understand where the actual problems were and what's necessary to fix them.
>>
>> Helge
>>
>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 4:43 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 16:00, Daniel Vetter wrote:
> > On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
> >>
> >> Hello Daniel,
> >>
> >> On 1/17/22 11:02, Daniel Vetter wrote:
> >>> Hi Helge
> >>>
> >>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
> >>>>
> >>>> The fbdev layer is orphaned, but seems to need some care.
> >>>> So I'd like to step up as new maintainer.
> >>>>
> >>>> Signed-off-by: Helge Deller <deller@gmx.de>
> >>>>
> >>>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>>> index 5d0cd537803a..ce47dbc467cc 100644
> >>>> --- a/MAINTAINERS
> >>>> +++ b/MAINTAINERS
> >>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
> >>>>  F:     arch/x86/math-emu/
> >>>>
> >>>>  FRAMEBUFFER LAYER
> >>>> -L:     dri-devel@lists.freedesktop.org
> >>>> +M:     Helge Deller <deller@gmx.de>
> >>>>  L:     linux-fbdev@vger.kernel.org
> >>>> -S:     Orphan
> >>>
> >>> Maybe don't rush maintainer changes in over the w/e without even bothering
> >>> to get any input from the people who've been maintaining it before.
> >>>
> >>> Because the status isn't entirely correct, fbdev core code and fbcon and
> >>> all that has been maintained, but in bugfixes only mode. And there's very
> >>> solid&important reasons to keep merging these patches through a drm tree,
> >>> because that's where all the driver development happens, and hence also
> >>> all the testing (e.g. the drm test suite has some fbdev tests - the only
> >>> automated ones that exist to my knowledge - and we run them in CI). So
> >>> moving that into an obscure new tree which isn't even in linux-next yet is
> >>> no good at all.
> >>>
> >>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> >>> welcome anyone stepping up for that, but the simplest approach there would
> >>> be to just get drm-misc commit rights and push the oddball bugfix in there
> >>> directly. But also if you want to do your own pull requests to Linus for
> >>> that I don't care and there's really no interference I think, so
> >>> whatever floats.
> >>>
> >>> But any code that is relevant for drm drivers really needs to go in through
> >>> drm trees, nothing else makes much sense.
> >>>
> >>> I guess you're first action as newly minted fbdev maintainer is going to be to
> >>> clean up the confusion you just created.
> >>
> >> Most of my machines depend on a working fbdev layer since drm isn't (and probably
> >> -due to technical requirements of DRM- won't be) available for those.
> >> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
> >>
> >> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
> >> For me it's really not important to drive any patches through a seperate tree, so
> >> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
> >> adding my tree to for-next was on my todo list...)
> >>
> >> What's important for me though is, to keep fbdev actively maintained, which means:
> >> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
> >
> > Yeah it'd be great if we have that, for a while Bart took care of
> > these, but had to step down again. drm-misc is maintained with the dim
> > scrip suite, which comes with docs and bash completion and everything.
> > Good starting pointer is here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
> >
> > Process for getting commit rights is documented here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
> >
> > But there's a pile more. I think once we've set that up and got it
> > going we can look at the bigger items. Some of them are fairly
> > low-hanging fruit, but the past 5+ years absolutely no one bothered to
> > step up and sort them out. Other problem areas in fbdev are extremely
> > hard to fix properly, without only doing minimal security-fixes only
> > support, so fair warning there. I think a good starting point would be
> > to read the patches and discussions for some of the things you've
> > reverted in your tree.
> >
> > Anyway I hope this gets you started, and hopefully after a minor
> > detour: Welcome to dri-devel, we're happy to take any help we can get,
> > there's lots to do!
> >
>
> Hello Daniel,
>
> you somehow missed to answer my main topics below...:

Well others replied on some specifics already, but for your reverts
really read the commit message first. fbcon is full or broken locking
and crashes that syzbot hits, so if you want to resurrect that code,
those bugs need to be fixed first. Or at least some way to make sure
that only people who don't care about serious issues in their kernel
can use the code. We haven't done much maintainering, but we've tried
to at least somewhat stay on top of the oopses and issues syzbot
discovers (not even all of them unfortunately).

Wrt useable console: shadow buffer + memcpy tends to be most
performant, actually useful 2d acceleration is really hard. See the
blog post Thomas linked. If you go with that, drm has you fully
covered.

None of the things you bring up are anything new really, and have been
discussed at length over the past 5-10 years here on dri-devel. That's
why I suggested that a good start is to focus on the simple fixes
first, and meanwhile ramp up on the complexity you're volunteering
for. There's some really tricky things going on here.
-Daniel

> >
> >> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >>    I know of at least one driver which won't be able to support DRM....
> >>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
> >> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> >>    either when run on native hardware or in an emulator.
> >> d) not break DRM development
> >>
> >> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> >> understand where the actual problems were and what's necessary to fix them.
> >>
> >> Helge
> >>
> >> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> >
> >
> >
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 4:43 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 16:00, Daniel Vetter wrote:
> > On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
> >>
> >> Hello Daniel,
> >>
> >> On 1/17/22 11:02, Daniel Vetter wrote:
> >>> Hi Helge
> >>>
> >>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
> >>>>
> >>>> The fbdev layer is orphaned, but seems to need some care.
> >>>> So I'd like to step up as new maintainer.
> >>>>
> >>>> Signed-off-by: Helge Deller <deller@gmx.de>
> >>>>
> >>>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>>> index 5d0cd537803a..ce47dbc467cc 100644
> >>>> --- a/MAINTAINERS
> >>>> +++ b/MAINTAINERS
> >>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
> >>>>  F:     arch/x86/math-emu/
> >>>>
> >>>>  FRAMEBUFFER LAYER
> >>>> -L:     dri-devel@lists.freedesktop.org
> >>>> +M:     Helge Deller <deller@gmx.de>
> >>>>  L:     linux-fbdev@vger.kernel.org
> >>>> -S:     Orphan
> >>>
> >>> Maybe don't rush maintainer changes in over the w/e without even bothering
> >>> to get any input from the people who've been maintaining it before.
> >>>
> >>> Because the status isn't entirely correct, fbdev core code and fbcon and
> >>> all that has been maintained, but in bugfixes only mode. And there's very
> >>> solid&important reasons to keep merging these patches through a drm tree,
> >>> because that's where all the driver development happens, and hence also
> >>> all the testing (e.g. the drm test suite has some fbdev tests - the only
> >>> automated ones that exist to my knowledge - and we run them in CI). So
> >>> moving that into an obscure new tree which isn't even in linux-next yet is
> >>> no good at all.
> >>>
> >>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> >>> welcome anyone stepping up for that, but the simplest approach there would
> >>> be to just get drm-misc commit rights and push the oddball bugfix in there
> >>> directly. But also if you want to do your own pull requests to Linus for
> >>> that I don't care and there's really no interference I think, so
> >>> whatever floats.
> >>>
> >>> But any code that is relevant for drm drivers really needs to go in through
> >>> drm trees, nothing else makes much sense.
> >>>
> >>> I guess you're first action as newly minted fbdev maintainer is going to be to
> >>> clean up the confusion you just created.
> >>
> >> Most of my machines depend on a working fbdev layer since drm isn't (and probably
> >> -due to technical requirements of DRM- won't be) available for those.
> >> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
> >>
> >> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
> >> For me it's really not important to drive any patches through a seperate tree, so
> >> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
> >> adding my tree to for-next was on my todo list...)
> >>
> >> What's important for me though is, to keep fbdev actively maintained, which means:
> >> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
> >
> > Yeah it'd be great if we have that, for a while Bart took care of
> > these, but had to step down again. drm-misc is maintained with the dim
> > scrip suite, which comes with docs and bash completion and everything.
> > Good starting pointer is here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
> >
> > Process for getting commit rights is documented here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
> >
> > But there's a pile more. I think once we've set that up and got it
> > going we can look at the bigger items. Some of them are fairly
> > low-hanging fruit, but the past 5+ years absolutely no one bothered to
> > step up and sort them out. Other problem areas in fbdev are extremely
> > hard to fix properly, without only doing minimal security-fixes only
> > support, so fair warning there. I think a good starting point would be
> > to read the patches and discussions for some of the things you've
> > reverted in your tree.
> >
> > Anyway I hope this gets you started, and hopefully after a minor
> > detour: Welcome to dri-devel, we're happy to take any help we can get,
> > there's lots to do!
> >
>
> Hello Daniel,
>
> you somehow missed to answer my main topics below...:

Well others replied on some specifics already, but for your reverts
really read the commit message first. fbcon is full or broken locking
and crashes that syzbot hits, so if you want to resurrect that code,
those bugs need to be fixed first. Or at least some way to make sure
that only people who don't care about serious issues in their kernel
can use the code. We haven't done much maintainering, but we've tried
to at least somewhat stay on top of the oopses and issues syzbot
discovers (not even all of them unfortunately).

Wrt useable console: shadow buffer + memcpy tends to be most
performant, actually useful 2d acceleration is really hard. See the
blog post Thomas linked. If you go with that, drm has you fully
covered.

None of the things you bring up are anything new really, and have been
discussed at length over the past 5-10 years here on dri-devel. That's
why I suggested that a good start is to focus on the simple fixes
first, and meanwhile ramp up on the complexity you're volunteering
for. There's some really tricky things going on here.
-Daniel

> >
> >> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
> >>    I know of at least one driver which won't be able to support DRM....
> >>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
> >> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> >>    either when run on native hardware or in an emulator.
> >> d) not break DRM development
> >>
> >> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> >> understand where the actual problems were and what's necessary to fix them.
> >>
> >> Helge
> >>
> >> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> >
> >
> >
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 911 bytes --]

Hi

Am 17.01.22 um 16:42 schrieb Helge Deller:
 > [...]
>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>     either when run on native hardware or in an emulator.
>>> d) not break DRM development
>>>
>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>> understand where the actual problems were and what's necessary to fix them.
>>>
>>> Helge
>>>
>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de

Seems like few people read linux-fbdev these days. I suggest to partly 
revert the patch to the point were performance gets better again.

Best regards
Thomas


>>
>>
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 911 bytes --]

Hi

Am 17.01.22 um 16:42 schrieb Helge Deller:
 > [...]
>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>     either when run on native hardware or in an emulator.
>>> d) not break DRM development
>>>
>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>> understand where the actual problems were and what's necessary to fix them.
>>>
>>> Helge
>>>
>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de

Seems like few people read linux-fbdev these days. I suggest to partly 
revert the patch to the point were performance gets better again.

Best regards
Thomas


>>
>>
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 16:58, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.22 um 16:42 schrieb Helge Deller:
>> [...]
>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>     either when run on native hardware or in an emulator.
>>>> d) not break DRM development
>>>>
>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>> understand where the actual problems were and what's necessary to fix them.
>>>>
>>>> Helge
>>>>
>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>
> Seems like few people read linux-fbdev these days.
> I suggest to partly revert the patch to the point were performance
> gets better again.
Yes, *please*!
That would solve my biggest concern.

As far as I can see that's only 2 commits to be reverted:
b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next

I think both were not related to any 0-day bug reports (but again, I might be wrong).

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 16:58, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.22 um 16:42 schrieb Helge Deller:
>> [...]
>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>     either when run on native hardware or in an emulator.
>>>> d) not break DRM development
>>>>
>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>> understand where the actual problems were and what's necessary to fix them.
>>>>
>>>> Helge
>>>>
>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>
> Seems like few people read linux-fbdev these days.
> I suggest to partly revert the patch to the point were performance
> gets better again.
Yes, *please*!
That would solve my biggest concern.

As far as I can see that's only 2 commits to be reverted:
b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next

I think both were not related to any 0-day bug reports (but again, I might be wrong).

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 5:22 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 16:58, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 17.01.22 um 16:42 schrieb Helge Deller:
> >> [...]
> >>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> >>>>     either when run on native hardware or in an emulator.
> >>>> d) not break DRM development
> >>>>
> >>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> >>>> understand where the actual problems were and what's necessary to fix them.
> >>>>
> >>>> Helge
> >>>>
> >>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> >
> > Seems like few people read linux-fbdev these days.
> > I suggest to partly revert the patch to the point were performance
> > gets better again.
> Yes, *please*!
> That would solve my biggest concern.
>
> As far as I can see that's only 2 commits to be reverted:
> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
>
> I think both were not related to any 0-day bug reports (but again, I might be wrong).

syzbot, not 0day, and there's like a sea of them unfortunately.
There's all kinds of funny races going on when resizing consoles (due
to bad locking design) which then blow up, especially in less tested
code. For the sw rendering we've merged a bunch of patches, but you
pretty much have to assume that it's all fairly broken code until it's
rewritten and fully covered with tests. Shadowfb + memcpy is probably
much faster for restoring scrolling performance than anything else
really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 5:22 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 16:58, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 17.01.22 um 16:42 schrieb Helge Deller:
> >> [...]
> >>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> >>>>     either when run on native hardware or in an emulator.
> >>>> d) not break DRM development
> >>>>
> >>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> >>>> understand where the actual problems were and what's necessary to fix them.
> >>>>
> >>>> Helge
> >>>>
> >>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> >
> > Seems like few people read linux-fbdev these days.
> > I suggest to partly revert the patch to the point were performance
> > gets better again.
> Yes, *please*!
> That would solve my biggest concern.
>
> As far as I can see that's only 2 commits to be reverted:
> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
>
> I think both were not related to any 0-day bug reports (but again, I might be wrong).

syzbot, not 0day, and there's like a sea of them unfortunately.
There's all kinds of funny races going on when resizing consoles (due
to bad locking design) which then blow up, especially in less tested
code. For the sw rendering we've merged a bunch of patches, but you
pretty much have to assume that it's all fairly broken code until it's
rewritten and fully covered with tests. Shadowfb + memcpy is probably
much faster for restoring scrolling performance than anything else
really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 17:38, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 5:22 PM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/17/22 16:58, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 17.01.22 um 16:42 schrieb Helge Deller:
>>>> [...]
>>>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>>>     either when run on native hardware or in an emulator.
>>>>>> d) not break DRM development
>>>>>>
>>>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>>>> understand where the actual problems were and what's necessary to fix them.
>>>>>>
>>>>>> Helge
>>>>>>
>>>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>>
>>> Seems like few people read linux-fbdev these days.
>>> I suggest to partly revert the patch to the point were performance
>>> gets better again.
>> Yes, *please*!
>> That would solve my biggest concern.
>>
>> As far as I can see that's only 2 commits to be reverted:
>> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
>> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
>>
>> I think both were not related to any 0-day bug reports (but again, I might be wrong).
>
> syzbot, not 0day, and there's like a sea of them unfortunately.
> There's all kinds of funny races going on when resizing consoles (due

The patches above are not about resizing consoles.
Even if a resize should happen in between, it's better to introduce some kind of big lock
instead of completely disable acceleration for est. 58 other graphic card drivers and slow them
down that much that it renders them to become unusable.

> to bad locking design) which then blow up, especially in less tested
> code. For the sw rendering we've merged a bunch of patches, but you
> pretty much have to assume that it's all fairly broken code until it's
> rewritten and fully covered with tests. Shadowfb + memcpy is probably
> much faster for restoring scrolling performance than anything else
> really.

That's maybe true for fast new machines with fast PCI busses.
But have you measured that on other/older hardware too?
There is a good reason why 2D acceleration was introduced.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 17:38, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 5:22 PM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/17/22 16:58, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 17.01.22 um 16:42 schrieb Helge Deller:
>>>> [...]
>>>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>>>     either when run on native hardware or in an emulator.
>>>>>> d) not break DRM development
>>>>>>
>>>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>>>> understand where the actual problems were and what's necessary to fix them.
>>>>>>
>>>>>> Helge
>>>>>>
>>>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>>
>>> Seems like few people read linux-fbdev these days.
>>> I suggest to partly revert the patch to the point were performance
>>> gets better again.
>> Yes, *please*!
>> That would solve my biggest concern.
>>
>> As far as I can see that's only 2 commits to be reverted:
>> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
>> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
>>
>> I think both were not related to any 0-day bug reports (but again, I might be wrong).
>
> syzbot, not 0day, and there's like a sea of them unfortunately.
> There's all kinds of funny races going on when resizing consoles (due

The patches above are not about resizing consoles.
Even if a resize should happen in between, it's better to introduce some kind of big lock
instead of completely disable acceleration for est. 58 other graphic card drivers and slow them
down that much that it renders them to become unusable.

> to bad locking design) which then blow up, especially in less tested
> code. For the sw rendering we've merged a bunch of patches, but you
> pretty much have to assume that it's all fairly broken code until it's
> rewritten and fully covered with tests. Shadowfb + memcpy is probably
> much faster for restoring scrolling performance than anything else
> really.

That's maybe true for fast new machines with fast PCI busses.
But have you measured that on other/older hardware too?
There is a good reason why 2D acceleration was introduced.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 17:21, Helge Deller wrote:
> On 1/17/22 16:58, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 17.01.22 um 16:42 schrieb Helge Deller:
>>> [...]
>>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>>     either when run on native hardware or in an emulator.
>>>>> d) not break DRM development
>>>>>
>>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>>> understand where the actual problems were and what's necessary to fix them.
>>>>>
>>>>> Helge
>>>>>
>>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>
>> Seems like few people read linux-fbdev these days.
>> I suggest to partly revert the patch to the point were performance
>> gets better again.
> Yes, *please*!
> That would solve my biggest concern.
>
> As far as I can see that's only 2 commits to be reverted:
> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
>
> I think both were not related to any 0-day bug reports (but again, I might be wrong).

I did some more checking...

Both patches are not related to DRM, since no DRM driver sets the
FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags.

Reverting those would bring back fbdev performance which I'm worried most about.
And it introduces no (positive or negative) effects on DRM.

I still wonder why those were submitted.
Let's please revert those.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 17:21, Helge Deller wrote:
> On 1/17/22 16:58, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 17.01.22 um 16:42 schrieb Helge Deller:
>>> [...]
>>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>>     either when run on native hardware or in an emulator.
>>>>> d) not break DRM development
>>>>>
>>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>>> understand where the actual problems were and what's necessary to fix them.
>>>>>
>>>>> Helge
>>>>>
>>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>
>> Seems like few people read linux-fbdev these days.
>> I suggest to partly revert the patch to the point were performance
>> gets better again.
> Yes, *please*!
> That would solve my biggest concern.
>
> As far as I can see that's only 2 commits to be reverted:
> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
>
> I think both were not related to any 0-day bug reports (but again, I might be wrong).

I did some more checking...

Both patches are not related to DRM, since no DRM driver sets the
FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags.

Reverting those would bring back fbdev performance which I'm worried most about.
And it introduces no (positive or negative) effects on DRM.

I still wonder why those were submitted.
Let's please revert those.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Ilia Mirkin]

On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 17:21, Helge Deller wrote:
> > On 1/17/22 16:58, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 17.01.22 um 16:42 schrieb Helge Deller:
> >>> [...]
> >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> >>>>>     either when run on native hardware or in an emulator.
> >>>>> d) not break DRM development
> >>>>>
> >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> >>>>> understand where the actual problems were and what's necessary to fix them.
> >>>>>
> >>>>> Helge
> >>>>>
> >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> >>
> >> Seems like few people read linux-fbdev these days.
> >> I suggest to partly revert the patch to the point were performance
> >> gets better again.
> > Yes, *please*!
> > That would solve my biggest concern.
> >
> > As far as I can see that's only 2 commits to be reverted:
> > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
> >
> > I think both were not related to any 0-day bug reports (but again, I might be wrong).
>
> I did some more checking...
>
> Both patches are not related to DRM, since no DRM driver sets the
> FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags.

These used to be set by, at least, nouveau (which is a drm driver).
And yeah, console responsiveness is _way_ worse without that. People
keep pushing the messaging that it's the same speed to do it as
memcpy, but that's just not the case in my experience, on a pretty
bog-standard x86 desktop. The support got dumped, and it felt pretty
clear from the messaging at the time, "too bad". Would love to see it
come back.

Cheers,

  -ilia

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Ilia Mirkin]

On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@gmx.de> wrote:
>
> On 1/17/22 17:21, Helge Deller wrote:
> > On 1/17/22 16:58, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 17.01.22 um 16:42 schrieb Helge Deller:
> >>> [...]
> >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> >>>>>     either when run on native hardware or in an emulator.
> >>>>> d) not break DRM development
> >>>>>
> >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> >>>>> understand where the actual problems were and what's necessary to fix them.
> >>>>>
> >>>>> Helge
> >>>>>
> >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> >>
> >> Seems like few people read linux-fbdev these days.
> >> I suggest to partly revert the patch to the point were performance
> >> gets better again.
> > Yes, *please*!
> > That would solve my biggest concern.
> >
> > As far as I can see that's only 2 commits to be reverted:
> > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
> >
> > I think both were not related to any 0-day bug reports (but again, I might be wrong).
>
> I did some more checking...
>
> Both patches are not related to DRM, since no DRM driver sets the
> FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags.

These used to be set by, at least, nouveau (which is a drm driver).
And yeah, console responsiveness is _way_ worse without that. People
keep pushing the messaging that it's the same speed to do it as
memcpy, but that's just not the case in my experience, on a pretty
bog-standard x86 desktop. The support got dumped, and it felt pretty
clear from the messaging at the time, "too bad". Would love to see it
come back.

Cheers,

  -ilia

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 10:55 PM Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>
> On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@gmx.de> wrote:
> >
> > On 1/17/22 17:21, Helge Deller wrote:
> > > On 1/17/22 16:58, Thomas Zimmermann wrote:
> > >> Hi
> > >>
> > >> Am 17.01.22 um 16:42 schrieb Helge Deller:
> > >>> [...]
> > >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> > >>>>>     either when run on native hardware or in an emulator.
> > >>>>> d) not break DRM development
> > >>>>>
> > >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> > >>>>> understand where the actual problems were and what's necessary to fix them.
> > >>>>>
> > >>>>> Helge
> > >>>>>
> > >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> > >>
> > >> Seems like few people read linux-fbdev these days.
> > >> I suggest to partly revert the patch to the point were performance
> > >> gets better again.
> > > Yes, *please*!
> > > That would solve my biggest concern.
> > >
> > > As far as I can see that's only 2 commits to be reverted:
> > > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> > > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
> > >
> > > I think both were not related to any 0-day bug reports (but again, I might be wrong).
> >
> > I did some more checking...
> >
> > Both patches are not related to DRM, since no DRM driver sets the
> > FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags.
>
> These used to be set by, at least, nouveau (which is a drm driver).
> And yeah, console responsiveness is _way_ worse without that. People
> keep pushing the messaging that it's the same speed to do it as
> memcpy, but that's just not the case in my experience, on a pretty
> bog-standard x86 desktop. The support got dumped, and it felt pretty
> clear from the messaging at the time, "too bad". Would love to see it
> come back.

You need to add in a shadow buffer and it's fast. The problem is that
the default fbcon sw code just replaces a hw blitter, and so does a
_lot_ of memmoves reading from wc/uc memory. Which is an absolute
disaster and results in a slideshow.

Once you stop doing that the thing is pretty reasonable, which would
also be what all the userspace sw compositors are doing. Fact that no
one bothers to roll this out for most drivers just shows how little
people care about accelerated fbcon.
-Daniel


>
> Cheers,
>
>   -ilia



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 17, 2022 at 10:55 PM Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>
> On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@gmx.de> wrote:
> >
> > On 1/17/22 17:21, Helge Deller wrote:
> > > On 1/17/22 16:58, Thomas Zimmermann wrote:
> > >> Hi
> > >>
> > >> Am 17.01.22 um 16:42 schrieb Helge Deller:
> > >>> [...]
> > >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> > >>>>>     either when run on native hardware or in an emulator.
> > >>>>> d) not break DRM development
> > >>>>>
> > >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> > >>>>> understand where the actual problems were and what's necessary to fix them.
> > >>>>>
> > >>>>> Helge
> > >>>>>
> > >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
> > >>
> > >> Seems like few people read linux-fbdev these days.
> > >> I suggest to partly revert the patch to the point were performance
> > >> gets better again.
> > > Yes, *please*!
> > > That would solve my biggest concern.
> > >
> > > As far as I can see that's only 2 commits to be reverted:
> > > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> > > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
> > >
> > > I think both were not related to any 0-day bug reports (but again, I might be wrong).
> >
> > I did some more checking...
> >
> > Both patches are not related to DRM, since no DRM driver sets the
> > FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags.
>
> These used to be set by, at least, nouveau (which is a drm driver).
> And yeah, console responsiveness is _way_ worse without that. People
> keep pushing the messaging that it's the same speed to do it as
> memcpy, but that's just not the case in my experience, on a pretty
> bog-standard x86 desktop. The support got dumped, and it felt pretty
> clear from the messaging at the time, "too bad". Would love to see it
> come back.

You need to add in a shadow buffer and it's fast. The problem is that
the default fbcon sw code just replaces a hw blitter, and so does a
_lot_ of memmoves reading from wc/uc memory. Which is an absolute
disaster and results in a slideshow.

Once you stop doing that the thing is pretty reasonable, which would
also be what all the userspace sw compositors are doing. Fact that no
one bothers to roll this out for most drivers just shows how little
people care about accelerated fbcon.
-Daniel


>
> Cheers,
>
>   -ilia



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --]

Hi

Am 17.01.22 um 17:21 schrieb Helge Deller:
> On 1/17/22 16:58, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 17.01.22 um 16:42 schrieb Helge Deller:
>>> [...]
>>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>>      either when run on native hardware or in an emulator.
>>>>> d) not break DRM development
>>>>>
>>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>>> understand where the actual problems were and what's necessary to fix them.
>>>>>
>>>>> Helge
>>>>>
>>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>
>> Seems like few people read linux-fbdev these days.
>> I suggest to partly revert the patch to the point were performance
>> gets better again.

If you want that, you should send a patch.

Best regards
Thomas

> Yes, *please*!
> That would solve my biggest concern.
> 
> As far as I can see that's only 2 commits to be reverted:
> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
> 
> I think both were not related to any 0-day bug reports (but again, I might be wrong).
> 
> Helge

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --]

Hi

Am 17.01.22 um 17:21 schrieb Helge Deller:
> On 1/17/22 16:58, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 17.01.22 um 16:42 schrieb Helge Deller:
>>> [...]
>>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>>>      either when run on native hardware or in an emulator.
>>>>> d) not break DRM development
>>>>>
>>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>>>> understand where the actual problems were and what's necessary to fix them.
>>>>>
>>>>> Helge
>>>>>
>>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>
>> Seems like few people read linux-fbdev these days.
>> I suggest to partly revert the patch to the point were performance
>> gets better again.

If you want that, you should send a patch.

Best regards
Thomas

> Yes, *please*!
> That would solve my biggest concern.
> 
> As far as I can see that's only 2 commits to be reverted:
> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
> 
> I think both were not related to any 0-day bug reports (but again, I might be wrong).
> 
> Helge

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Jani Nikula]

On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Seems like few people read linux-fbdev these days.

How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
also? Do we still need a separate linux-fbdev mailing list at all?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Jani Nikula]

On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Seems like few people read linux-fbdev these days.

How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
also? Do we still need a separate linux-fbdev mailing list at all?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 22:40, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Seems like few people read linux-fbdev these days.
>
> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> also?

Doesn't seem like much traffic - which IMHO is OK for such a tree with
mostly just maintenance patches.

> Do we still need a separate linux-fbdev mailing list at all?

Yes. I want to have it seperate of dri-devel.
Actually I'd prefer to drop dri-devel from the list where patches
for fbdev are sent...

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/17/22 22:40, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Seems like few people read linux-fbdev these days.
>
> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> also?

Doesn't seem like much traffic - which IMHO is OK for such a tree with
mostly just maintenance patches.

> Do we still need a separate linux-fbdev mailing list at all?

Yes. I want to have it seperate of dri-devel.
Actually I'd prefer to drop dri-devel from the list where patches
for fbdev are sent...

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Jani Nikula]

On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> On 1/17/22 22:40, Jani Nikula wrote:
>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>> Seems like few people read linux-fbdev these days.
>>
>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>> also?
>
> Doesn't seem like much traffic - which IMHO is OK for such a tree with
> mostly just maintenance patches.
>
>> Do we still need a separate linux-fbdev mailing list at all?
>
> Yes. I want to have it seperate of dri-devel.
> Actually I'd prefer to drop dri-devel from the list where patches
> for fbdev are sent...

Disagreed. If anything, this thread shows we can't have fbdev and drm in
silos of their own.

Also, if the patches continue to get merged through drm-misc, they need
to be sent to dri-devel.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Jani Nikula]

On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> On 1/17/22 22:40, Jani Nikula wrote:
>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>> Seems like few people read linux-fbdev these days.
>>
>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>> also?
>
> Doesn't seem like much traffic - which IMHO is OK for such a tree with
> mostly just maintenance patches.
>
>> Do we still need a separate linux-fbdev mailing list at all?
>
> Yes. I want to have it seperate of dri-devel.
> Actually I'd prefer to drop dri-devel from the list where patches
> for fbdev are sent...

Disagreed. If anything, this thread shows we can't have fbdev and drm in
silos of their own.

Also, if the patches continue to get merged through drm-misc, they need
to be sent to dri-devel.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Jani,

On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> > On 1/17/22 22:40, Jani Nikula wrote:
> >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>> Seems like few people read linux-fbdev these days.
> >>
> >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> >> also?
> >
> > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > mostly just maintenance patches.
> >
> >> Do we still need a separate linux-fbdev mailing list at all?
> >
> > Yes. I want to have it seperate of dri-devel.
> > Actually I'd prefer to drop dri-devel from the list where patches
> > for fbdev are sent...
>
> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> silos of their own.

Unless DRM drops fbdev support. Isn't that the long-term plan anyway?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Jani,

On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> > On 1/17/22 22:40, Jani Nikula wrote:
> >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>> Seems like few people read linux-fbdev these days.
> >>
> >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> >> also?
> >
> > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > mostly just maintenance patches.
> >
> >> Do we still need a separate linux-fbdev mailing list at all?
> >
> > Yes. I want to have it seperate of dri-devel.
> > Actually I'd prefer to drop dri-devel from the list where patches
> > for fbdev are sent...
>
> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> silos of their own.

Unless DRM drops fbdev support. Isn't that the long-term plan anyway?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Jani,
>
> On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> > > On 1/17/22 22:40, Jani Nikula wrote:
> > >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > >>> Seems like few people read linux-fbdev these days.
> > >>
> > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> > >> also?
> > >
> > > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > > mostly just maintenance patches.
> > >
> > >> Do we still need a separate linux-fbdev mailing list at all?
> > >
> > > Yes. I want to have it seperate of dri-devel.
> > > Actually I'd prefer to drop dri-devel from the list where patches
> > > for fbdev are sent...
> >
> > Disagreed. If anything, this thread shows we can't have fbdev and drm in
> > silos of their own.
>
> Unless DRM drops fbdev support. Isn't that the long-term plan anyway?

No. There's way too much old stuff still using the fbdev interface to
do that. We've even done things like standardize the vblank wait
ioctl, because people need that.

There's some effort to make fbdev drivers like efifb obsolete, and
there's been discussions to have a drm-native fbcon. But none of these
are going to make fbdev on top of drm obsolete and something we can
remove. Pretty sure at least not this decade.
-Daniel

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Jani,
>
> On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> > > On 1/17/22 22:40, Jani Nikula wrote:
> > >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > >>> Seems like few people read linux-fbdev these days.
> > >>
> > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> > >> also?
> > >
> > > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > > mostly just maintenance patches.
> > >
> > >> Do we still need a separate linux-fbdev mailing list at all?
> > >
> > > Yes. I want to have it seperate of dri-devel.
> > > Actually I'd prefer to drop dri-devel from the list where patches
> > > for fbdev are sent...
> >
> > Disagreed. If anything, this thread shows we can't have fbdev and drm in
> > silos of their own.
>
> Unless DRM drops fbdev support. Isn't that the long-term plan anyway?

No. There's way too much old stuff still using the fbdev interface to
do that. We've even done things like standardize the vblank wait
ioctl, because people need that.

There's some effort to make fbdev drivers like efifb obsolete, and
there's been discussions to have a drm-native fbcon. But none of these
are going to make fbdev on top of drm obsolete and something we can
remove. Pretty sure at least not this decade.
-Daniel

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Simon Ser]

On Tuesday, January 18th, 2022 at 12:41, Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Jani,
> >
> > On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> > > > On 1/17/22 22:40, Jani Nikula wrote:
> > > >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > > >>> Seems like few people read linux-fbdev these days.
> > > >>
> > > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> > > >> also?
> > > >
> > > > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > > > mostly just maintenance patches.
> > > >
> > > >> Do we still need a separate linux-fbdev mailing list at all?
> > > >
> > > > Yes. I want to have it seperate of dri-devel.
> > > > Actually I'd prefer to drop dri-devel from the list where patches
> > > > for fbdev are sent...
> > >
> > > Disagreed. If anything, this thread shows we can't have fbdev and drm in
> > > silos of their own.
> >
> > Unless DRM drops fbdev support. Isn't that the long-term plan anyway?
>
> No. There's way too much old stuff still using the fbdev interface to
> do that. We've even done things like standardize the vblank wait
> ioctl, because people need that.

Kind of related: I wonder, could we document somewhere that fbdev is a
deprecated uAPI? ie. new user-space shouldn't use it and should prefer DRM.
I don't see that mentioned anywhere, although it seems like it's the
consensus among all kernel developers I've talked to.

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Simon Ser]

On Tuesday, January 18th, 2022 at 12:41, Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Jani,
> >
> > On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> > > > On 1/17/22 22:40, Jani Nikula wrote:
> > > >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > > >>> Seems like few people read linux-fbdev these days.
> > > >>
> > > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> > > >> also?
> > > >
> > > > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > > > mostly just maintenance patches.
> > > >
> > > >> Do we still need a separate linux-fbdev mailing list at all?
> > > >
> > > > Yes. I want to have it seperate of dri-devel.
> > > > Actually I'd prefer to drop dri-devel from the list where patches
> > > > for fbdev are sent...
> > >
> > > Disagreed. If anything, this thread shows we can't have fbdev and drm in
> > > silos of their own.
> >
> > Unless DRM drops fbdev support. Isn't that the long-term plan anyway?
>
> No. There's way too much old stuff still using the fbdev interface to
> do that. We've even done things like standardize the vblank wait
> ioctl, because people need that.

Kind of related: I wonder, could we document somewhere that fbdev is a
deprecated uAPI? ie. new user-space shouldn't use it and should prefer DRM.
I don't see that mentioned anywhere, although it seems like it's the
consensus among all kernel developers I've talked to.

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 09:38, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
>> On 1/17/22 22:40, Jani Nikula wrote:
>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>> Seems like few people read linux-fbdev these days.
>>>
>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>>> also?
>>
>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
>> mostly just maintenance patches.
>>
>>> Do we still need a separate linux-fbdev mailing list at all?
>>
>> Yes. I want to have it seperate of dri-devel.
>> Actually I'd prefer to drop dri-devel from the list where patches
>> for fbdev are sent...
>
> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> silos of their own.

Patches to fbdev usually don't affect DRM.
Patches which affect DRM needs to through to dri-devel.
In addition this would take the burden of the dri-developers to receive
unrelated fbdev driver updates and patches.

> Also, if the patches continue to get merged through drm-misc, they need
> to be sent to dri-devel.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 09:38, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
>> On 1/17/22 22:40, Jani Nikula wrote:
>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>> Seems like few people read linux-fbdev these days.
>>>
>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>>> also?
>>
>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
>> mostly just maintenance patches.
>>
>>> Do we still need a separate linux-fbdev mailing list at all?
>>
>> Yes. I want to have it seperate of dri-devel.
>> Actually I'd prefer to drop dri-devel from the list where patches
>> for fbdev are sent...
>
> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> silos of their own.

Patches to fbdev usually don't affect DRM.
Patches which affect DRM needs to through to dri-devel.
In addition this would take the burden of the dri-developers to receive
unrelated fbdev driver updates and patches.

> Also, if the patches continue to get merged through drm-misc, they need
> to be sent to dri-devel.

Helge

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Javier Martinez Canillas]

On 1/18/22 09:54, Helge Deller wrote:
> On 1/18/22 09:38, Jani Nikula wrote:
>> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
>>> On 1/17/22 22:40, Jani Nikula wrote:
>>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>> Seems like few people read linux-fbdev these days.
>>>>
>>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>>>> also?
>>>
>>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
>>> mostly just maintenance patches.
>>>
>>>> Do we still need a separate linux-fbdev mailing list at all?
>>>
>>> Yes. I want to have it seperate of dri-devel.
>>> Actually I'd prefer to drop dri-devel from the list where patches
>>> for fbdev are sent...
>>
>> Disagreed. If anything, this thread shows we can't have fbdev and drm in
>> silos of their own.
> 
> Patches to fbdev usually don't affect DRM.

Patches for fbdev drivers don't usually affect DRM but that's not the
case for patches to fbdev core and fbcon as you and others mentioned.

> Patches which affect DRM needs to through to dri-devel.

And how would people know which ones need to go through dri-devel ? Are
you planning to add another entry to MAINTAINERS for fbdev core/fbcon ?

> In addition this would take the burden of the dri-developers to receive
> unrelated fbdev driver updates and patches.
>

In my opinion having fbdev patches in the dri-devel mailing list isn't
a big burden, but rather getting people to review and push say patches.

Since you are volunteering for the latter, that should improve things.

I still fail to see the benefit of doing that split, same for having a
separate fbdev tree. Using drm-misc only have advantages, among other
things providing redundancy in cases that a maintainer isn't available
for a period of time.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Javier Martinez Canillas]

On 1/18/22 09:54, Helge Deller wrote:
> On 1/18/22 09:38, Jani Nikula wrote:
>> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
>>> On 1/17/22 22:40, Jani Nikula wrote:
>>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>> Seems like few people read linux-fbdev these days.
>>>>
>>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>>>> also?
>>>
>>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
>>> mostly just maintenance patches.
>>>
>>>> Do we still need a separate linux-fbdev mailing list at all?
>>>
>>> Yes. I want to have it seperate of dri-devel.
>>> Actually I'd prefer to drop dri-devel from the list where patches
>>> for fbdev are sent...
>>
>> Disagreed. If anything, this thread shows we can't have fbdev and drm in
>> silos of their own.
> 
> Patches to fbdev usually don't affect DRM.

Patches for fbdev drivers don't usually affect DRM but that's not the
case for patches to fbdev core and fbcon as you and others mentioned.

> Patches which affect DRM needs to through to dri-devel.

And how would people know which ones need to go through dri-devel ? Are
you planning to add another entry to MAINTAINERS for fbdev core/fbcon ?

> In addition this would take the burden of the dri-developers to receive
> unrelated fbdev driver updates and patches.
>

In my opinion having fbdev patches in the dri-devel mailing list isn't
a big burden, but rather getting people to review and push say patches.

Since you are volunteering for the latter, that should improve things.

I still fail to see the benefit of doing that split, same for having a
separate fbdev tree. Using drm-misc only have advantages, among other
things providing redundancy in cases that a maintainer isn't available
for a period of time.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Javier,

On Tue, Jan 18, 2022 at 10:33 AM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> On 1/18/22 09:54, Helge Deller wrote:
> > On 1/18/22 09:38, Jani Nikula wrote:
> >> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> >>> On 1/17/22 22:40, Jani Nikula wrote:
> >>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>>>> Seems like few people read linux-fbdev these days.
> >>>>
> >>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> >>>> also?
> >>>
> >>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
> >>> mostly just maintenance patches.
> >>>
> >>>> Do we still need a separate linux-fbdev mailing list at all?
> >>>
> >>> Yes. I want to have it seperate of dri-devel.
> >>> Actually I'd prefer to drop dri-devel from the list where patches
> >>> for fbdev are sent...
> >>
> >> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> >> silos of their own.
> >
> > Patches to fbdev usually don't affect DRM.
>
> Patches for fbdev drivers don't usually affect DRM but that's not the
> case for patches to fbdev core and fbcon as you and others mentioned.
>
> > Patches which affect DRM needs to through to dri-devel.
>
> And how would people know which ones need to go through dri-devel ? Are
> you planning to add another entry to MAINTAINERS for fbdev core/fbcon ?

Those are nicely contained in drivers/video/fbdev/core/, so an entry
in MAINTAINERS listing both linux-fbdev and dri-devel would do.

> > In addition this would take the burden of the dri-developers to receive
> > unrelated fbdev driver updates and patches.
>
> In my opinion having fbdev patches in the dri-devel mailing list isn't
> a big burden, but rather getting people to review and push say patches.
>
> Since you are volunteering for the latter, that should improve things.
>
> I still fail to see the benefit of doing that split, same for having a
> separate fbdev tree. Using drm-misc only have advantages, among other
> things providing redundancy in cases that a maintainer isn't available
> for a period of time.

The above is the point of view from a DRM developer?
For an fbdev developer, the burden to receive unrelated DRM driver
updates and patches would be significant.

The first page of https://lore.kernel.org/dri-devel/ goes back to yesterday.
The first page of https://lore.kernel.org/linux-fbdev/ goes back to Nov 30th.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Javier,

On Tue, Jan 18, 2022 at 10:33 AM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> On 1/18/22 09:54, Helge Deller wrote:
> > On 1/18/22 09:38, Jani Nikula wrote:
> >> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> >>> On 1/17/22 22:40, Jani Nikula wrote:
> >>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>>>> Seems like few people read linux-fbdev these days.
> >>>>
> >>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> >>>> also?
> >>>
> >>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
> >>> mostly just maintenance patches.
> >>>
> >>>> Do we still need a separate linux-fbdev mailing list at all?
> >>>
> >>> Yes. I want to have it seperate of dri-devel.
> >>> Actually I'd prefer to drop dri-devel from the list where patches
> >>> for fbdev are sent...
> >>
> >> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> >> silos of their own.
> >
> > Patches to fbdev usually don't affect DRM.
>
> Patches for fbdev drivers don't usually affect DRM but that's not the
> case for patches to fbdev core and fbcon as you and others mentioned.
>
> > Patches which affect DRM needs to through to dri-devel.
>
> And how would people know which ones need to go through dri-devel ? Are
> you planning to add another entry to MAINTAINERS for fbdev core/fbcon ?

Those are nicely contained in drivers/video/fbdev/core/, so an entry
in MAINTAINERS listing both linux-fbdev and dri-devel would do.

> > In addition this would take the burden of the dri-developers to receive
> > unrelated fbdev driver updates and patches.
>
> In my opinion having fbdev patches in the dri-devel mailing list isn't
> a big burden, but rather getting people to review and push say patches.
>
> Since you are volunteering for the latter, that should improve things.
>
> I still fail to see the benefit of doing that split, same for having a
> separate fbdev tree. Using drm-misc only have advantages, among other
> things providing redundancy in cases that a maintainer isn't available
> for a period of time.

The above is the point of view from a DRM developer?
For an fbdev developer, the burden to receive unrelated DRM driver
updates and patches would be significant.

The first page of https://lore.kernel.org/dri-devel/ goes back to yesterday.
The first page of https://lore.kernel.org/linux-fbdev/ goes back to Nov 30th.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@gmx.de> wrote:
>
> On 1/18/22 09:38, Jani Nikula wrote:
> > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> >> On 1/17/22 22:40, Jani Nikula wrote:
> >>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>>> Seems like few people read linux-fbdev these days.
> >>>
> >>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> >>> also?
> >>
> >> Doesn't seem like much traffic - which IMHO is OK for such a tree with
> >> mostly just maintenance patches.
> >>
> >>> Do we still need a separate linux-fbdev mailing list at all?
> >>
> >> Yes. I want to have it seperate of dri-devel.
> >> Actually I'd prefer to drop dri-devel from the list where patches
> >> for fbdev are sent...
> >
> > Disagreed. If anything, this thread shows we can't have fbdev and drm in
> > silos of their own.
>
> Patches to fbdev usually don't affect DRM.
> Patches which affect DRM needs to through to dri-devel.
> In addition this would take the burden of the dri-developers to receive
> unrelated fbdev driver updates and patches.

I added dri-devel for fbdev because stuff landed that shouldn't have.
Let's not remove that, because the amount of patches for fbdev which
arent relevant for drm drivers is pretty much nothing.

I really don't like the idea that fbdev goes off again becoming a
silo, just because it's too hard to wire through low-bit greyscale
support. Which no I can't type for you, because I don't have such hw
here.

Everything where people cared enough for adding fbdev compat support
for to actually write a patch is supported.

If you do want a silo  for fbdev then I think the only reasonable
option is that we create a copy of the fbdev/fbcon code for drm
(somewhat renamed), so that you can do the reverts without impacting
drm drivers. But there will still be some overlap and minimal
coordination, plus I'm not seeing anyone from the drm side
volunteering for the sizeable amount of work.
-Daniel

> > Also, if the patches continue to get merged through drm-misc, they need
> > to be sent to dri-devel.
>
> Helge



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@gmx.de> wrote:
>
> On 1/18/22 09:38, Jani Nikula wrote:
> > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
> >> On 1/17/22 22:40, Jani Nikula wrote:
> >>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>>> Seems like few people read linux-fbdev these days.
> >>>
> >>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> >>> also?
> >>
> >> Doesn't seem like much traffic - which IMHO is OK for such a tree with
> >> mostly just maintenance patches.
> >>
> >>> Do we still need a separate linux-fbdev mailing list at all?
> >>
> >> Yes. I want to have it seperate of dri-devel.
> >> Actually I'd prefer to drop dri-devel from the list where patches
> >> for fbdev are sent...
> >
> > Disagreed. If anything, this thread shows we can't have fbdev and drm in
> > silos of their own.
>
> Patches to fbdev usually don't affect DRM.
> Patches which affect DRM needs to through to dri-devel.
> In addition this would take the burden of the dri-developers to receive
> unrelated fbdev driver updates and patches.

I added dri-devel for fbdev because stuff landed that shouldn't have.
Let's not remove that, because the amount of patches for fbdev which
arent relevant for drm drivers is pretty much nothing.

I really don't like the idea that fbdev goes off again becoming a
silo, just because it's too hard to wire through low-bit greyscale
support. Which no I can't type for you, because I don't have such hw
here.

Everything where people cared enough for adding fbdev compat support
for to actually write a patch is supported.

If you do want a silo  for fbdev then I think the only reasonable
option is that we create a copy of the fbdev/fbcon code for drm
(somewhat renamed), so that you can do the reverts without impacting
drm drivers. But there will still be some overlap and minimal
coordination, plus I'm not seeing anyone from the drm side
volunteering for the sizeable amount of work.
-Daniel

> > Also, if the patches continue to get merged through drm-misc, they need
> > to be sent to dri-devel.
>
> Helge



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

	On 1/18/22 12:18, Daniel Vetter wrote:
> On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/18/22 09:38, Jani Nikula wrote:
>>> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
>>>> On 1/17/22 22:40, Jani Nikula wrote:
>>>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>>> Seems like few people read linux-fbdev these days.
>>>>>
>>>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>>>>> also?
>>>>
>>>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
>>>> mostly just maintenance patches.
>>>>
>>>>> Do we still need a separate linux-fbdev mailing list at all?
>>>>
>>>> Yes. I want to have it seperate of dri-devel.
>>>> Actually I'd prefer to drop dri-devel from the list where patches
>>>> for fbdev are sent...
>>>
>>> Disagreed. If anything, this thread shows we can't have fbdev and drm in
>>> silos of their own.
>>
>> Patches to fbdev usually don't affect DRM.
>> Patches which affect DRM needs to through to dri-devel.
>> In addition this would take the burden of the dri-developers to receive
>> unrelated fbdev driver updates and patches.
>
> I added dri-devel for fbdev because stuff landed that shouldn't have.
> Let's not remove that, because the amount of patches for fbdev which
> arent relevant for drm drivers is pretty much nothing.

I'm fine with keeping both lists mentioned in the MAINTAINERS file.
It was a proposal and I understand you want to keep it. Ok for me.

> I really don't like the idea that fbdev goes off again becoming a
> silo, just because it's too hard to wire through low-bit greyscale
> support. Which no I can't type for you, because I don't have such hw
> here.
>
> Everything where people cared enough for adding fbdev compat support
> for to actually write a patch is supported.
>
> If you do want a silo  for fbdev then I think the only reasonable
> option is that we create a copy of the fbdev/fbcon code for drm
> (somewhat renamed), so that you can do the reverts without impacting
> drm drivers.

I don't see *any impact* on drm drivers at all if both patches would be
reverted now.

> But there will still be some overlap and minimal
> coordination, plus I'm not seeing anyone from the drm side
> volunteering for the sizeable amount of work.

I wonder why you don't want to give it a try?
My current proposal is to revert those two changes.
Reverting them does not affect DRM code.

Both DRM and some fbdev drivers still share excactly the same code paths in the SCROLL_REDRAW case.
In addition there are some fbdev drivers which provide 2D support and instead allow SCROLL_MOVE.
That's it.

Currently I don't know which other cleanups or refactorings of fbcon are
planned from DRM side, but I'm sure there is a easy way to keep both supported.

If it then really turns out that it's not possible we can decide then how
to continue.

Helge

> -Daniel
>
>>> Also, if the patches continue to get merged through drm-misc, they need
>>> to be sent to dri-devel.
>>
>> Helge
>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

	On 1/18/22 12:18, Daniel Vetter wrote:
> On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/18/22 09:38, Jani Nikula wrote:
>>> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote:
>>>> On 1/17/22 22:40, Jani Nikula wrote:
>>>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>>> Seems like few people read linux-fbdev these days.
>>>>>
>>>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>>>>> also?
>>>>
>>>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
>>>> mostly just maintenance patches.
>>>>
>>>>> Do we still need a separate linux-fbdev mailing list at all?
>>>>
>>>> Yes. I want to have it seperate of dri-devel.
>>>> Actually I'd prefer to drop dri-devel from the list where patches
>>>> for fbdev are sent...
>>>
>>> Disagreed. If anything, this thread shows we can't have fbdev and drm in
>>> silos of their own.
>>
>> Patches to fbdev usually don't affect DRM.
>> Patches which affect DRM needs to through to dri-devel.
>> In addition this would take the burden of the dri-developers to receive
>> unrelated fbdev driver updates and patches.
>
> I added dri-devel for fbdev because stuff landed that shouldn't have.
> Let's not remove that, because the amount of patches for fbdev which
> arent relevant for drm drivers is pretty much nothing.

I'm fine with keeping both lists mentioned in the MAINTAINERS file.
It was a proposal and I understand you want to keep it. Ok for me.

> I really don't like the idea that fbdev goes off again becoming a
> silo, just because it's too hard to wire through low-bit greyscale
> support. Which no I can't type for you, because I don't have such hw
> here.
>
> Everything where people cared enough for adding fbdev compat support
> for to actually write a patch is supported.
>
> If you do want a silo  for fbdev then I think the only reasonable
> option is that we create a copy of the fbdev/fbcon code for drm
> (somewhat renamed), so that you can do the reverts without impacting
> drm drivers.

I don't see *any impact* on drm drivers at all if both patches would be
reverted now.

> But there will still be some overlap and minimal
> coordination, plus I'm not seeing anyone from the drm side
> volunteering for the sizeable amount of work.

I wonder why you don't want to give it a try?
My current proposal is to revert those two changes.
Reverting them does not affect DRM code.

Both DRM and some fbdev drivers still share excactly the same code paths in the SCROLL_REDRAW case.
In addition there are some fbdev drivers which provide 2D support and instead allow SCROLL_MOVE.
That's it.

Currently I don't know which other cleanups or refactorings of fbcon are
planned from DRM side, but I'm sure there is a easy way to keep both supported.

If it then really turns out that it's not possible we can decide then how
to continue.

Helge

> -Daniel
>
>>> Also, if the patches continue to get merged through drm-misc, they need
>>> to be sent to dri-devel.
>>
>> Helge
>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hello Daniel,

On 1/17/22 16:00, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>> On 1/17/22 11:02, Daniel Vetter wrote:
>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> The fbdev layer is orphaned, but seems to need some care.
>>>> So I'd like to step up as new maintainer.
>>>>
>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 5d0cd537803a..ce47dbc467cc 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>>  F:     arch/x86/math-emu/
>>>>
>>>>  FRAMEBUFFER LAYER
>>>> -L:     dri-devel@lists.freedesktop.org
>>>> +M:     Helge Deller <deller@gmx.de>
>>>>  L:     linux-fbdev@vger.kernel.org
>>>> -S:     Orphan
>>>
>>> Maybe don't rush maintainer changes in over the w/e without even bothering
>>> to get any input from the people who've been maintaining it before.
>>>
>>> Because the status isn't entirely correct, fbdev core code and fbcon and
>>> all that has been maintained, but in bugfixes only mode. And there's very
>>> solid&important reasons to keep merging these patches through a drm tree,
>>> because that's where all the driver development happens, and hence also
>>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>>> automated ones that exist to my knowledge - and we run them in CI). So
>>> moving that into an obscure new tree which isn't even in linux-next yet is
>>> no good at all.
>>>
>>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>>> welcome anyone stepping up for that, but the simplest approach there would
>>> be to just get drm-misc commit rights and push the oddball bugfix in there
>>> directly. But also if you want to do your own pull requests to Linus for
>>> that I don't care and there's really no interference I think, so
>>> whatever floats.
>>>
>>> But any code that is relevant for drm drivers really needs to go in through
>>> drm trees, nothing else makes much sense.
>>>
>>> I guess you're first action as newly minted fbdev maintainer is going to be to
>>> clean up the confusion you just created.
>>
>> Most of my machines depend on a working fbdev layer since drm isn't (and probably
>> -due to technical requirements of DRM- won't be) available for those.
>> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>>
>> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
>> For me it's really not important to drive any patches through a seperate tree, so
>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
>> adding my tree to for-next was on my todo list...)
>>
>> What's important for me though is, to keep fbdev actively maintained, which means:
>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
>
> Yeah it'd be great if we have that, for a while Bart took care of
> these, but had to step down again. drm-misc is maintained with the dim
> scrip suite, which comes with docs and bash completion and everything.
> Good starting pointer is here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>
> Process for getting commit rights is documented here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
>
> But there's a pile more. I think once we've set that up and got it
> going we can look at the bigger items. Some of them are fairly
> low-hanging fruit, but the past 5+ years absolutely no one bothered to
> step up and sort them out. Other problem areas in fbdev are extremely
> hard to fix properly, without only doing minimal security-fixes only
> support, so fair warning there. I think a good starting point would be
> to read the patches and discussions for some of the things you've
> reverted in your tree.
>
> Anyway I hope this gets you started, and hopefully after a minor
> detour: Welcome to dri-devel, we're happy to take any help we can get,
> there's lots to do!

Thanks for this info, Daniel!

After reading those docs I've decided not to join dri-devel and keep
my existing linux-fbdev tree at:

https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git

The linux-fbdev is a low-volume mailing list with mostly small bug fixes
or enhancements for the fbdev drivers. Those patches usually don't affect DRM.

I'm expecting that non-trivial changes which may affect fbdev will be sent to the
linux-fbdev mailing list, same way as I will of course send any patches which
might affect DRM to dri-devel.

My git tree is wired up to the for-next pull chain, so in any way we would notice
merge conflicts (which I believe will not happen).

Cheers,

Helge

>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>    I know of at least one driver which won't be able to support DRM....
>>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>    either when run on native hardware or in an emulator.
>> d) not break DRM development
>>
>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>> understand where the actual problems were and what's necessary to fix them.
>>
>> Helge
>>
>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hello Daniel,

On 1/17/22 16:00, Daniel Vetter wrote:
> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>> On 1/17/22 11:02, Daniel Vetter wrote:
>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> The fbdev layer is orphaned, but seems to need some care.
>>>> So I'd like to step up as new maintainer.
>>>>
>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 5d0cd537803a..ce47dbc467cc 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>>  F:     arch/x86/math-emu/
>>>>
>>>>  FRAMEBUFFER LAYER
>>>> -L:     dri-devel@lists.freedesktop.org
>>>> +M:     Helge Deller <deller@gmx.de>
>>>>  L:     linux-fbdev@vger.kernel.org
>>>> -S:     Orphan
>>>
>>> Maybe don't rush maintainer changes in over the w/e without even bothering
>>> to get any input from the people who've been maintaining it before.
>>>
>>> Because the status isn't entirely correct, fbdev core code and fbcon and
>>> all that has been maintained, but in bugfixes only mode. And there's very
>>> solid&important reasons to keep merging these patches through a drm tree,
>>> because that's where all the driver development happens, and hence also
>>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>>> automated ones that exist to my knowledge - and we run them in CI). So
>>> moving that into an obscure new tree which isn't even in linux-next yet is
>>> no good at all.
>>>
>>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>>> welcome anyone stepping up for that, but the simplest approach there would
>>> be to just get drm-misc commit rights and push the oddball bugfix in there
>>> directly. But also if you want to do your own pull requests to Linus for
>>> that I don't care and there's really no interference I think, so
>>> whatever floats.
>>>
>>> But any code that is relevant for drm drivers really needs to go in through
>>> drm trees, nothing else makes much sense.
>>>
>>> I guess you're first action as newly minted fbdev maintainer is going to be to
>>> clean up the confusion you just created.
>>
>> Most of my machines depend on a working fbdev layer since drm isn't (and probably
>> -due to technical requirements of DRM- won't be) available for those.
>> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>>
>> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
>> For me it's really not important to drive any patches through a seperate tree, so
>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
>> adding my tree to for-next was on my todo list...)
>>
>> What's important for me though is, to keep fbdev actively maintained, which means:
>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
>
> Yeah it'd be great if we have that, for a while Bart took care of
> these, but had to step down again. drm-misc is maintained with the dim
> scrip suite, which comes with docs and bash completion and everything.
> Good starting pointer is here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>
> Process for getting commit rights is documented here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
>
> But there's a pile more. I think once we've set that up and got it
> going we can look at the bigger items. Some of them are fairly
> low-hanging fruit, but the past 5+ years absolutely no one bothered to
> step up and sort them out. Other problem areas in fbdev are extremely
> hard to fix properly, without only doing minimal security-fixes only
> support, so fair warning there. I think a good starting point would be
> to read the patches and discussions for some of the things you've
> reverted in your tree.
>
> Anyway I hope this gets you started, and hopefully after a minor
> detour: Welcome to dri-devel, we're happy to take any help we can get,
> there's lots to do!

Thanks for this info, Daniel!

After reading those docs I've decided not to join dri-devel and keep
my existing linux-fbdev tree at:

https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git

The linux-fbdev is a low-volume mailing list with mostly small bug fixes
or enhancements for the fbdev drivers. Those patches usually don't affect DRM.

I'm expecting that non-trivial changes which may affect fbdev will be sent to the
linux-fbdev mailing list, same way as I will of course send any patches which
might affect DRM to dri-devel.

My git tree is wired up to the for-next pull chain, so in any way we would notice
merge conflicts (which I believe will not happen).

Cheers,

Helge

>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>    I know of at least one driver which won't be able to support DRM....
>>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>    either when run on native hardware or in an emulator.
>> d) not break DRM development
>>
>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>> understand where the actual problems were and what's necessary to fix them.
>>
>> Helge
>>
>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>
>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 09:41, Helge Deller wrote:
> Hello Daniel,
>
> On 1/17/22 16:00, Daniel Vetter wrote:
>> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>>> On 1/17/22 11:02, Daniel Vetter wrote:
>>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>>>
>>>>> The fbdev layer is orphaned, but seems to need some care.
>>>>> So I'd like to step up as new maintainer.
>>>>>
>>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>>
>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>> index 5d0cd537803a..ce47dbc467cc 100644
>>>>> --- a/MAINTAINERS
>>>>> +++ b/MAINTAINERS
>>>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>>>  F:     arch/x86/math-emu/
>>>>>
>>>>>  FRAMEBUFFER LAYER
>>>>> -L:     dri-devel@lists.freedesktop.org
>>>>> +M:     Helge Deller <deller@gmx.de>
>>>>>  L:     linux-fbdev@vger.kernel.org
>>>>> -S:     Orphan
>>>>
>>>> Maybe don't rush maintainer changes in over the w/e without even bothering
>>>> to get any input from the people who've been maintaining it before.
>>>>
>>>> Because the status isn't entirely correct, fbdev core code and fbcon and
>>>> all that has been maintained, but in bugfixes only mode. And there's very
>>>> solid&important reasons to keep merging these patches through a drm tree,
>>>> because that's where all the driver development happens, and hence also
>>>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>>>> automated ones that exist to my knowledge - and we run them in CI). So
>>>> moving that into an obscure new tree which isn't even in linux-next yet is
>>>> no good at all.
>>>>
>>>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>>>> welcome anyone stepping up for that, but the simplest approach there would
>>>> be to just get drm-misc commit rights and push the oddball bugfix in there
>>>> directly. But also if you want to do your own pull requests to Linus for
>>>> that I don't care and there's really no interference I think, so
>>>> whatever floats.
>>>>
>>>> But any code that is relevant for drm drivers really needs to go in through
>>>> drm trees, nothing else makes much sense.
>>>>
>>>> I guess you're first action as newly minted fbdev maintainer is going to be to
>>>> clean up the confusion you just created.
>>>
>>> Most of my machines depend on a working fbdev layer since drm isn't (and probably
>>> -due to technical requirements of DRM- won't be) available for those.
>>> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>>>
>>> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
>>> For me it's really not important to drive any patches through a seperate tree, so
>>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
>>> adding my tree to for-next was on my todo list...)
>>>
>>> What's important for me though is, to keep fbdev actively maintained, which means:
>>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
>>
>> Yeah it'd be great if we have that, for a while Bart took care of
>> these, but had to step down again. drm-misc is maintained with the dim
>> scrip suite, which comes with docs and bash completion and everything.
>> Good starting pointer is here:
>>
>> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>>
>> Process for getting commit rights is documented here:
>>
>> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
>>
>> But there's a pile more. I think once we've set that up and got it
>> going we can look at the bigger items. Some of them are fairly
>> low-hanging fruit, but the past 5+ years absolutely no one bothered to
>> step up and sort them out. Other problem areas in fbdev are extremely
>> hard to fix properly, without only doing minimal security-fixes only
>> support, so fair warning there. I think a good starting point would be
>> to read the patches and discussions for some of the things you've
>> reverted in your tree.
>>
>> Anyway I hope this gets you started, and hopefully after a minor
>> detour: Welcome to dri-devel, we're happy to take any help we can get,
>> there's lots to do!
>
> Thanks for this info, Daniel!
>
> After reading those docs I've decided not to join dri-devel and keep
> my existing linux-fbdev tree at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>
> The linux-fbdev is a low-volume mailing list with mostly small bug fixes
> or enhancements for the fbdev drivers. Those patches usually don't affect DRM.
>
> I'm expecting that non-trivial changes which may affect fbdev will be sent to the
> linux-fbdev mailing list, same way as I will of course send any patches which
> might affect DRM to dri-devel.
>
> My git tree is wired up to the for-next pull chain, so in any way we would notice
> merge conflicts (which I believe will not happen).

To make it more clear:
I'm not planning to push code to fbdev/fbcon without having discussed everything
on dri-devel. Everything which somehow would affect DRM needs to be discussed on
dri-devel and then - after agreement - either pushed via the fbdev git tree or
the drm-misc tree.

Helge

> Cheers,
>
> Helge
>
>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>    I know of at least one driver which won't be able to support DRM....
>>>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>    either when run on native hardware or in an emulator.
>>> d) not break DRM development
>>>
>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>> understand where the actual problems were and what's necessary to fix them.
>>>
>>> Helge
>>>
>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>
>>
>>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

On 1/18/22 09:41, Helge Deller wrote:
> Hello Daniel,
>
> On 1/17/22 16:00, Daniel Vetter wrote:
>> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote:
>>> On 1/17/22 11:02, Daniel Vetter wrote:
>>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote:
>>>>>
>>>>> The fbdev layer is orphaned, but seems to need some care.
>>>>> So I'd like to step up as new maintainer.
>>>>>
>>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>>
>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>> index 5d0cd537803a..ce47dbc467cc 100644
>>>>> --- a/MAINTAINERS
>>>>> +++ b/MAINTAINERS
>>>>> @@ -7583,11 +7583,12 @@ W:      http://floatingpoint.sourceforge.net/emulator/index.html
>>>>>  F:     arch/x86/math-emu/
>>>>>
>>>>>  FRAMEBUFFER LAYER
>>>>> -L:     dri-devel@lists.freedesktop.org
>>>>> +M:     Helge Deller <deller@gmx.de>
>>>>>  L:     linux-fbdev@vger.kernel.org
>>>>> -S:     Orphan
>>>>
>>>> Maybe don't rush maintainer changes in over the w/e without even bothering
>>>> to get any input from the people who've been maintaining it before.
>>>>
>>>> Because the status isn't entirely correct, fbdev core code and fbcon and
>>>> all that has been maintained, but in bugfixes only mode. And there's very
>>>> solid&important reasons to keep merging these patches through a drm tree,
>>>> because that's where all the driver development happens, and hence also
>>>> all the testing (e.g. the drm test suite has some fbdev tests - the only
>>>> automated ones that exist to my knowledge - and we run them in CI). So
>>>> moving that into an obscure new tree which isn't even in linux-next yet is
>>>> no good at all.
>>>>
>>>> Now fbdev driver bugfixes is indeed practically orphaned and I very much
>>>> welcome anyone stepping up for that, but the simplest approach there would
>>>> be to just get drm-misc commit rights and push the oddball bugfix in there
>>>> directly. But also if you want to do your own pull requests to Linus for
>>>> that I don't care and there's really no interference I think, so
>>>> whatever floats.
>>>>
>>>> But any code that is relevant for drm drivers really needs to go in through
>>>> drm trees, nothing else makes much sense.
>>>>
>>>> I guess you're first action as newly minted fbdev maintainer is going to be to
>>>> clean up the confusion you just created.
>>>
>>> Most of my machines depend on a working fbdev layer since drm isn't (and probably
>>> -due to technical requirements of DRM- won't be) available for those.
>>> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer.
>>>
>>> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev.
>>> For me it's really not important to drive any patches through a seperate tree, so
>>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way,
>>> adding my tree to for-next was on my todo list...)
>>>
>>> What's important for me though is, to keep fbdev actively maintained, which means:
>>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct,
>>
>> Yeah it'd be great if we have that, for a while Bart took care of
>> these, but had to step down again. drm-misc is maintained with the dim
>> scrip suite, which comes with docs and bash completion and everything.
>> Good starting pointer is here:
>>
>> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>>
>> Process for getting commit rights is documented here:
>>
>> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
>>
>> But there's a pile more. I think once we've set that up and got it
>> going we can look at the bigger items. Some of them are fairly
>> low-hanging fruit, but the past 5+ years absolutely no one bothered to
>> step up and sort them out. Other problem areas in fbdev are extremely
>> hard to fix properly, without only doing minimal security-fixes only
>> support, so fair warning there. I think a good starting point would be
>> to read the patches and discussions for some of the things you've
>> reverted in your tree.
>>
>> Anyway I hope this gets you started, and hopefully after a minor
>> detour: Welcome to dri-devel, we're happy to take any help we can get,
>> there's lots to do!
>
> Thanks for this info, Daniel!
>
> After reading those docs I've decided not to join dri-devel and keep
> my existing linux-fbdev tree at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>
> The linux-fbdev is a low-volume mailing list with mostly small bug fixes
> or enhancements for the fbdev drivers. Those patches usually don't affect DRM.
>
> I'm expecting that non-trivial changes which may affect fbdev will be sent to the
> linux-fbdev mailing list, same way as I will of course send any patches which
> might affect DRM to dri-devel.
>
> My git tree is wired up to the for-next pull chain, so in any way we would notice
> merge conflicts (which I believe will not happen).

To make it more clear:
I'm not planning to push code to fbdev/fbcon without having discussed everything
on dri-devel. Everything which somehow would affect DRM needs to be discussed on
dri-devel and then - after agreement - either pushed via the fbdev git tree or
the drm-misc tree.

Helge

> Cheers,
>
> Helge
>
>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>    I know of at least one driver which won't be able to support DRM....
>>>    Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev.
>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
>>>    either when run on native hardware or in an emulator.
>>> d) not break DRM development
>>>
>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
>>> understand where the actual problems were and what's necessary to fix them.
>>>
>>> Helge
>>>
>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
>>
>>
>>
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2068 bytes --]

Hi

Am 14.01.22 um 19:11 schrieb Helge Deller:
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
> 
> Signed-off-by: Helge Deller <deller@gmx.de>

First of all, thank you for stepping up to maintain the fbdev codebase. 
It really needs someone actively looking after it.

And now comes the BUT.

I want to second everything said by Danial and Javier. In addition to 
purely organizational topics (trees, PRs, etc), there are a number of 
inherit problems with fbdev.

  * It's 90s technology. Neither does it fit today's userspace, not 
hardware. If you have more than just the most trivial of graphical 
output fbdev isn't for you.

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

  * A few use-cases for efifb remain, but distributions are actively 
moving away from fbdev. I know that at least openSUSE, Fedora and Alpine 
do this.

I'd like to hear what your plans are for fbdev?

Best regards
Thomas

> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d0cd537803a..ce47dbc467cc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7583,11 +7583,12 @@ W:	http://floatingpoint.sourceforge.net/emulator/index.html
>   F:	arch/x86/math-emu/
> 
>   FRAMEBUFFER LAYER
> -L:	dri-devel@lists.freedesktop.org
> +M:	Helge Deller <deller@gmx.de>
>   L:	linux-fbdev@vger.kernel.org
> -S:	Orphan
> +L:	dri-devel@lists.freedesktop.org
> +S:	Maintained
>   Q:	http://patchwork.kernel.org/project/linux-fbdev/list/
> -T:	git git://anongit.freedesktop.org/drm/drm-misc
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>   F:	Documentation/fb/
>   F:	drivers/video/
>   F:	include/linux/fb.h

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Helge Deller]

Hi Thomas,

On 1/17/22 12:16, Thomas Zimmermann wrote:
> Hi
>
> Am 14.01.22 um 19:11 schrieb Helge Deller:
>> The fbdev layer is orphaned, but seems to need some care.
>> So I'd like to step up as new maintainer.
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>
> First of all, thank you for stepping up to maintain the fbdev
> codebase. It really needs someone actively looking after it.

Thanks.

> And now comes the BUT.
>
> I want to second everything said by Danial and Javier. In addition to
> purely organizational topics (trees, PRs, etc), there are a number of
> inherit problems with fbdev.

I will answer that in the other mail to Daniel shortly...

> * It's 90s technology. Neither does it fit today's userspace, not
> hardware. If you have more than just the most trivial of graphical
> output fbdev isn't for you.

Right.
I'm working and maintaining such hardware.
There is not just x86, there is not just Intel/AMD/nvidia graphics
and for those fbdev is still (and will be) important.

> * There's no new development in fbdev and there are no new drivers.
> Everyone works on DRM, which is better in most regards.

In most regards yes.
So, don't get me wrong.
I fully agree DRM that is the way forward.
But on the way forward we shouldn't try to actively break code for others.

> The consequence is that userspace is slowly loosing the ability to
> use fbdev.
Maybe.

> * A few use-cases for efifb remain, but distributions are actively
> moving away from fbdev. I know that at least openSUSE, Fedora and
> Alpine do this.

Debian is still running on lots of hardware, either which isn't x86 or
which is old hardware.
The distributions you mentioned still need fbdev for machines were DRM isn't
available (yet).

> I'd like to hear what your plans are for fbdev?

That's easy:
* To maintain it.
* To keep it working for where DRM can't be used.
* My goal is NOT to work against DRM. That's the future of course.

Helge

>
> Best regards
> Thomas
>
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d0cd537803a..ce47dbc467cc 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7583,11 +7583,12 @@ W:    http://floatingpoint.sourceforge.net/emulator/index.html
>>   F:    arch/x86/math-emu/
>>
>>   FRAMEBUFFER LAYER
>> -L:    dri-devel@lists.freedesktop.org
>> +M:    Helge Deller <deller@gmx.de>
>>   L:    linux-fbdev@vger.kernel.org
>> -S:    Orphan
>> +L:    dri-devel@lists.freedesktop.org
>> +S:    Maintained
>>   Q:    http://patchwork.kernel.org/project/linux-fbdev/list/
>> -T:    git git://anongit.freedesktop.org/drm/drm-misc
>> +T:    git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>>   F:    Documentation/fb/
>>   F:    drivers/video/
>>   F:    include/linux/fb.h
>

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 5109 bytes --]

Hi

Am 17.01.22 um 12:33 schrieb Helge Deller:
> Hi Thomas,
> 
> On 1/17/22 12:16, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 14.01.22 um 19:11 schrieb Helge Deller:
>>> The fbdev layer is orphaned, but seems to need some care.
>>> So I'd like to step up as new maintainer.
>>>
>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> First of all, thank you for stepping up to maintain the fbdev
>> codebase. It really needs someone actively looking after it.
> 
> Thanks.
> 
>> And now comes the BUT.
>>
>> I want to second everything said by Danial and Javier. In addition to
>> purely organizational topics (trees, PRs, etc), there are a number of
>> inherit problems with fbdev.
> 
> I will answer that in the other mail to Daniel shortly...
> 
>> * It's 90s technology. Neither does it fit today's userspace, not
>> hardware. If you have more than just the most trivial of graphical
>> output fbdev isn't for you.
> 
> Right.
> I'm working and maintaining such hardware.
> There is not just x86, there is not just Intel/AMD/nvidia graphics
> and for those fbdev is still (and will be) important.
> 
>> * There's no new development in fbdev and there are no new drivers.
>> Everyone works on DRM, which is better in most regards.
> 
> In most regards yes.
> So, don't get me wrong.
> I fully agree DRM that is the way forward.
> But on the way forward we shouldn't try to actively break code for others.

We don't actively break fbdev for anyone. Actually, after ~20yrs we 
finally added testcases for fbdev ioctls, so that we avoid regressions.

> 
>> The consequence is that userspace is slowly loosing the ability to
>> use fbdev.
> Maybe.

There might be outliers, but I don't think the Linux desktops support 
fbdev in Wayland mode. For Weston, the last thing I heard was that fbdev 
is supposed to be dropped in one of the next releases.

Fbdev is mostly handled by old Xorg or maybe whatever embedded vendors 
implement. Note the DRM drivers still support fbdev interfaces via 
/dev/fb* for legacy userspace.

> 
>> * A few use-cases for efifb remain, but distributions are actively
>> moving away from fbdev. I know that at least openSUSE, Fedora and
>> Alpine do this.
> 
> Debian is still running on lots of hardware, either which isn't x86 or
> which is old hardware.
> The distributions you mentioned still need fbdev for machines were DRM isn't
> available (yet).

Not really. From [1], Alpine apparently switched already. openSUSE [2] 
and Fedora [3] are in the process of doing so. Debian can easily follow.

We now do have the ability to run DRM from early stages of the boot 
process without the need for fbdev. What we still use is the fbcon 
console. There are ideas to replace that as well.

> 
>> I'd like to hear what your plans are for fbdev?
> 
> That's easy:
> * To maintain it.
> * To keep it working for where DRM can't be used.
> * My goal is NOT to work against DRM. That's the future of course.
> 

IMHO that second bullet really misses the point. DRM can be used where 
ever fbdev is still required. The only thing stopping it is the 
availability of a hardware driver.

A meaning contribution would be to port fbdev drivers over to DRM. That 
makes modern features available on that hardware in both, kernel and 
userspace. We do take drivers for old hardware. I even made 
fbdev-conversion helpers a while ago. [4]

If you can point to graphics hardware that should have a DRM driver, 
I'll help any volunteers with the conversion.

But keeping fbdev alive for such hardware only contributes to the 
fragmentation and makes these systems even more obsolete.

Best regards
Thomas

[1] https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.15
[2] https://bugzilla.opensuse.org/show_bug.cgi?id=1193250
[3] https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers
[4] 
https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/fbconv-plus-drivers

> Helge
> 
>>
>> Best regards
>> Thomas
>>
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 5d0cd537803a..ce47dbc467cc 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7583,11 +7583,12 @@ W:    http://floatingpoint.sourceforge.net/emulator/index.html
>>>    F:    arch/x86/math-emu/
>>>
>>>    FRAMEBUFFER LAYER
>>> -L:    dri-devel@lists.freedesktop.org
>>> +M:    Helge Deller <deller@gmx.de>
>>>    L:    linux-fbdev@vger.kernel.org
>>> -S:    Orphan
>>> +L:    dri-devel@lists.freedesktop.org
>>> +S:    Maintained
>>>    Q:    http://patchwork.kernel.org/project/linux-fbdev/list/
>>> -T:    git git://anongit.freedesktop.org/drm/drm-misc
>>> +T:    git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
>>>    F:    Documentation/fb/
>>>    F:    drivers/video/
>>>    F:    include/linux/fb.h
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Sven Schnelle]

Hi Thomas,

Thomas Zimmermann <tzimmermann@suse.de> writes:

> Hi
>
> Am 14.01.22 um 19:11 schrieb Helge Deller:
>> The fbdev layer is orphaned, but seems to need some care.
>> So I'd like to step up as new maintainer.
>> Signed-off-by: Helge Deller <deller@gmx.de>
>
> First of all, thank you for stepping up to maintain the fbdev
> codebase. It really needs someone actively looking after it.
>
> And now comes the BUT.
>
> I want to second everything said by Danial and Javier. In addition to
> purely organizational topics (trees, PRs, etc), there are a number of
> inherit problems with fbdev.
>
>  * It's 90s technology. Neither does it fit today's userspace, not
>    hardware. If you have more than just the most trivial of graphical
>    output fbdev isn't for you.
>
>  * 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.

I also tested the speed on my Thinkpad X1 with Intel graphics, and there
a dmesg with 919 lines one the text console took about 2s to display. In
x11, i measure 22ms. This might be unfair because encoding might be
different, but i cannot confirm the 'memcpy' is faster than hardware
blitting' point. I think if that would be the case, no-one would care
about 2D acceleration.

Don't get me wrong, i'm not saying there's no reason for DRM. I fully
understand why it exists and think it's a good way to go. But for system
where a (fast) local console is required without X11, fbdev might be the
better choice at the moment.

Regards
Sven

[1] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m57cdea83608fc78bfc6c2e76eb037bf82017b302
[2] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m46a52815036a958f6a11d2f3f62e1340a09bd981

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Mon, 17 Jan 2022 19:47:39 +0100
Sven Schnelle <svens@stackframe.org> wrote:

> I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> a dmesg with 919 lines one the text console took about 2s to display. In
> x11, i measure 22ms. This might be unfair because encoding might be
> different, but i cannot confirm the 'memcpy' is faster than hardware
> blitting' point. I think if that would be the case, no-one would care
> about 2D acceleration.

I think that is an extremely unfair comparison, because a graphical
terminal app is not going to render every line of text streamed to it.
It probably renders only the final view alone if you simply run
'dmesg', skipping the first 800-900 lines completely.

Maybe fbcon should do the same when presented with a flood of text,
but I don't know how or why it works like it works. I assume in your
two second test you actually see some scrolling (animation) rather than
the final view? Or does it take 2 seconds just to update one screenful?

I doubt your fbcon and terminal window had height of 919 lines?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Mon, 17 Jan 2022 19:47:39 +0100
Sven Schnelle <svens@stackframe.org> wrote:

> I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> a dmesg with 919 lines one the text console took about 2s to display. In
> x11, i measure 22ms. This might be unfair because encoding might be
> different, but i cannot confirm the 'memcpy' is faster than hardware
> blitting' point. I think if that would be the case, no-one would care
> about 2D acceleration.

I think that is an extremely unfair comparison, because a graphical
terminal app is not going to render every line of text streamed to it.
It probably renders only the final view alone if you simply run
'dmesg', skipping the first 800-900 lines completely.

Maybe fbcon should do the same when presented with a flood of text,
but I don't know how or why it works like it works. I assume in your
two second test you actually see some scrolling (animation) rather than
the final view? Or does it take 2 seconds just to update one screenful?

I doubt your fbcon and terminal window had height of 919 lines?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> On Mon, 17 Jan 2022 19:47:39 +0100
> Sven Schnelle <svens@stackframe.org> wrote:
> 
> > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > a dmesg with 919 lines one the text console took about 2s to display. In
> > x11, i measure 22ms. This might be unfair because encoding might be
> > different, but i cannot confirm the 'memcpy' is faster than hardware
> > blitting' point. I think if that would be the case, no-one would care
> > about 2D acceleration.
> 
> I think that is an extremely unfair comparison, because a graphical
> terminal app is not going to render every line of text streamed to it.
> It probably renders only the final view alone if you simply run
> 'dmesg', skipping the first 800-900 lines completely.

Probably more like "render on every vblank", but yes, unlike fbcon it
surely wouldn't render every single character sent to the terminal.

Also acceleration on modern hardware is more like "compose window
content using the 3d engine" than "use 2d blitter to scroll the window".

> Maybe fbcon should do the same when presented with a flood of text,
> but I don't know how or why it works like it works.

fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
doing it synchronously.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> On Mon, 17 Jan 2022 19:47:39 +0100
> Sven Schnelle <svens@stackframe.org> wrote:
> 
> > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > a dmesg with 919 lines one the text console took about 2s to display. In
> > x11, i measure 22ms. This might be unfair because encoding might be
> > different, but i cannot confirm the 'memcpy' is faster than hardware
> > blitting' point. I think if that would be the case, no-one would care
> > about 2D acceleration.
> 
> I think that is an extremely unfair comparison, because a graphical
> terminal app is not going to render every line of text streamed to it.
> It probably renders only the final view alone if you simply run
> 'dmesg', skipping the first 800-900 lines completely.

Probably more like "render on every vblank", but yes, unlike fbcon it
surely wouldn't render every single character sent to the terminal.

Also acceleration on modern hardware is more like "compose window
content using the 3d engine" than "use 2d blitter to scroll the window".

> Maybe fbcon should do the same when presented with a flood of text,
> but I don't know how or why it works like it works.

fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
doing it synchronously.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 10:54 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > On Mon, 17 Jan 2022 19:47:39 +0100
> > Sven Schnelle <svens@stackframe.org> wrote:
> >
> > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > x11, i measure 22ms. This might be unfair because encoding might be
> > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > blitting' point. I think if that would be the case, no-one would care
> > > about 2D acceleration.
> >
> > I think that is an extremely unfair comparison, because a graphical
> > terminal app is not going to render every line of text streamed to it.
> > It probably renders only the final view alone if you simply run
> > 'dmesg', skipping the first 800-900 lines completely.
>
> Probably more like "render on every vblank", but yes, unlike fbcon it
> surely wouldn't render every single character sent to the terminal.
>
> Also acceleration on modern hardware is more like "compose window
> content using the 3d engine" than "use 2d blitter to scroll the window".
>
> > Maybe fbcon should do the same when presented with a flood of text,
> > but I don't know how or why it works like it works.
>
> fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> doing it synchronously.

Yeah, and if you use the shadow fb support in drm fbdev helpers,
that's what you get. Maybe we should just make that the default, since
that would also greatly simply stuff like modesetting support for
fbdev.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Tue, Jan 18, 2022 at 10:54 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > On Mon, 17 Jan 2022 19:47:39 +0100
> > Sven Schnelle <svens@stackframe.org> wrote:
> >
> > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > x11, i measure 22ms. This might be unfair because encoding might be
> > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > blitting' point. I think if that would be the case, no-one would care
> > > about 2D acceleration.
> >
> > I think that is an extremely unfair comparison, because a graphical
> > terminal app is not going to render every line of text streamed to it.
> > It probably renders only the final view alone if you simply run
> > 'dmesg', skipping the first 800-900 lines completely.
>
> Probably more like "render on every vblank", but yes, unlike fbcon it
> surely wouldn't render every single character sent to the terminal.
>
> Also acceleration on modern hardware is more like "compose window
> content using the 3d engine" than "use 2d blitter to scroll the window".
>
> > Maybe fbcon should do the same when presented with a flood of text,
> > but I don't know how or why it works like it works.
>
> fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> doing it synchronously.

Yeah, and if you use the shadow fb support in drm fbdev helpers,
that's what you get. Maybe we should just make that the default, since
that would also greatly simply stuff like modesetting support for
fbdev.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
> 
> Yeah, and if you use the shadow fb support in drm fbdev helpers,
> that's what you get. Maybe we should just make that the default, since
> that would also greatly simply stuff like modesetting support for
> fbdev.

Yep, that helps of course.  I was thinking more about the chars + attrs
+ font -> framebuffer step in the fbcon rendering pipeline though where
one could do something simliar to save even more cpu cycles.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
> 
> Yeah, and if you use the shadow fb support in drm fbdev helpers,
> that's what you get. Maybe we should just make that the default, since
> that would also greatly simply stuff like modesetting support for
> fbdev.

Yep, that helps of course.  I was thinking more about the chars + attrs
+ font -> framebuffer step in the fbcon rendering pipeline though where
one could do something simliar to save even more cpu cycles.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Tue, 18 Jan 2022 10:53:52 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > On Mon, 17 Jan 2022 19:47:39 +0100
> > Sven Schnelle <svens@stackframe.org> wrote:
> >   
> > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > x11, i measure 22ms. This might be unfair because encoding might be
> > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > blitting' point. I think if that would be the case, no-one would care
> > > about 2D acceleration.  
> > 
> > I think that is an extremely unfair comparison, because a graphical
> > terminal app is not going to render every line of text streamed to it.
> > It probably renders only the final view alone if you simply run
> > 'dmesg', skipping the first 800-900 lines completely.  
> 
> Probably more like "render on every vblank", but yes, unlike fbcon it
> surely wouldn't render every single character sent to the terminal.

Yes, and since 1k lines of dmesg is such little data, I would guess
even an old machine can chew that up in much less than one refresh
period until it needs to draw, so there is only going to be one or two
screen updates to be drawn.

Also, since X11 does not have vblank or frame boundaries in the
protocol, a terminal emulator app will do render throttling somehow
else. Maybe when it temporarily exhausts input and a timer as a
deadline in case input just keeps on flooding, would be my wild guess.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Tue, 18 Jan 2022 10:53:52 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > On Mon, 17 Jan 2022 19:47:39 +0100
> > Sven Schnelle <svens@stackframe.org> wrote:
> >   
> > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > x11, i measure 22ms. This might be unfair because encoding might be
> > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > blitting' point. I think if that would be the case, no-one would care
> > > about 2D acceleration.  
> > 
> > I think that is an extremely unfair comparison, because a graphical
> > terminal app is not going to render every line of text streamed to it.
> > It probably renders only the final view alone if you simply run
> > 'dmesg', skipping the first 800-900 lines completely.  
> 
> Probably more like "render on every vblank", but yes, unlike fbcon it
> surely wouldn't render every single character sent to the terminal.

Yes, and since 1k lines of dmesg is such little data, I would guess
even an old machine can chew that up in much less than one refresh
period until it needs to draw, so there is only going to be one or two
screen updates to be drawn.

Also, since X11 does not have vblank or frame boundaries in the
protocol, a terminal emulator app will do render throttling somehow
else. Maybe when it temporarily exhausts input and a timer as a
deadline in case input just keeps on flooding, would be my wild guess.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Gerd,

On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > On Mon, 17 Jan 2022 19:47:39 +0100
> > Sven Schnelle <svens@stackframe.org> wrote:
> >
> > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > x11, i measure 22ms. This might be unfair because encoding might be
> > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > blitting' point. I think if that would be the case, no-one would care
> > > about 2D acceleration.
> >
> > I think that is an extremely unfair comparison, because a graphical
> > terminal app is not going to render every line of text streamed to it.
> > It probably renders only the final view alone if you simply run
> > 'dmesg', skipping the first 800-900 lines completely.
>
> Probably more like "render on every vblank", but yes, unlike fbcon it
> surely wouldn't render every single character sent to the terminal.
>
> Also acceleration on modern hardware is more like "compose window
> content using the 3d engine" than "use 2d blitter to scroll the window".
>
> > Maybe fbcon should do the same when presented with a flood of text,
> > but I don't know how or why it works like it works.
>
> fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> doing it synchronously.

Hopefully only the parts of the screen which need a redraw?

Not all displays can be updated that fast. For a "modern" example, see
https://patchwork.freedesktop.org/series/93070/.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Gerd,

On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > On Mon, 17 Jan 2022 19:47:39 +0100
> > Sven Schnelle <svens@stackframe.org> wrote:
> >
> > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > x11, i measure 22ms. This might be unfair because encoding might be
> > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > blitting' point. I think if that would be the case, no-one would care
> > > about 2D acceleration.
> >
> > I think that is an extremely unfair comparison, because a graphical
> > terminal app is not going to render every line of text streamed to it.
> > It probably renders only the final view alone if you simply run
> > 'dmesg', skipping the first 800-900 lines completely.
>
> Probably more like "render on every vblank", but yes, unlike fbcon it
> surely wouldn't render every single character sent to the terminal.
>
> Also acceleration on modern hardware is more like "compose window
> content using the 3d engine" than "use 2d blitter to scroll the window".
>
> > Maybe fbcon should do the same when presented with a flood of text,
> > but I don't know how or why it works like it works.
>
> fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> doing it synchronously.

Hopefully only the parts of the screen which need a redraw?

Not all displays can be updated that fast. For a "modern" example, see
https://patchwork.freedesktop.org/series/93070/.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Gerd,
>
> On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > Sven Schnelle <svens@stackframe.org> wrote:
> > >
> > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > blitting' point. I think if that would be the case, no-one would care
> > > > about 2D acceleration.
> > >
> > > I think that is an extremely unfair comparison, because a graphical
> > > terminal app is not going to render every line of text streamed to it.
> > > It probably renders only the final view alone if you simply run
> > > 'dmesg', skipping the first 800-900 lines completely.
> >
> > Probably more like "render on every vblank", but yes, unlike fbcon it
> > surely wouldn't render every single character sent to the terminal.
> >
> > Also acceleration on modern hardware is more like "compose window
> > content using the 3d engine" than "use 2d blitter to scroll the window".
> >
> > > Maybe fbcon should do the same when presented with a flood of text,
> > > but I don't know how or why it works like it works.
> >
> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
>
> Hopefully only the parts of the screen which need a redraw?
>
> Not all displays can be updated that fast. For a "modern" example, see
> https://patchwork.freedesktop.org/series/93070/.

drm does damage tracking throughout the stack, e.g.

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties

And unlike fbdev, it's explicit (so less overhead since userspace
generally knows what it's drawn) and doesn't rely on page fault
intercepting and fun stuff like that.

Like do people actually know what drm can and cannot do, or would that
take out all the fun?
-Daniel

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Gerd,
>
> On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > Sven Schnelle <svens@stackframe.org> wrote:
> > >
> > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > blitting' point. I think if that would be the case, no-one would care
> > > > about 2D acceleration.
> > >
> > > I think that is an extremely unfair comparison, because a graphical
> > > terminal app is not going to render every line of text streamed to it.
> > > It probably renders only the final view alone if you simply run
> > > 'dmesg', skipping the first 800-900 lines completely.
> >
> > Probably more like "render on every vblank", but yes, unlike fbcon it
> > surely wouldn't render every single character sent to the terminal.
> >
> > Also acceleration on modern hardware is more like "compose window
> > content using the 3d engine" than "use 2d blitter to scroll the window".
> >
> > > Maybe fbcon should do the same when presented with a flood of text,
> > > but I don't know how or why it works like it works.
> >
> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
>
> Hopefully only the parts of the screen which need a redraw?
>
> Not all displays can be updated that fast. For a "modern" example, see
> https://patchwork.freedesktop.org/series/93070/.

drm does damage tracking throughout the stack, e.g.

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties

And unlike fbdev, it's explicit (so less overhead since userspace
generally knows what it's drawn) and doesn't rely on page fault
intercepting and fun stuff like that.

Like do people actually know what drm can and cannot do, or would that
take out all the fun?
-Daniel

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > > Sven Schnelle <svens@stackframe.org> wrote:
> > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > > blitting' point. I think if that would be the case, no-one would care
> > > > > about 2D acceleration.
> > > >
> > > > I think that is an extremely unfair comparison, because a graphical
> > > > terminal app is not going to render every line of text streamed to it.
> > > > It probably renders only the final view alone if you simply run
> > > > 'dmesg', skipping the first 800-900 lines completely.
> > >
> > > Probably more like "render on every vblank", but yes, unlike fbcon it
> > > surely wouldn't render every single character sent to the terminal.
> > >
> > > Also acceleration on modern hardware is more like "compose window
> > > content using the 3d engine" than "use 2d blitter to scroll the window".
> > >
> > > > Maybe fbcon should do the same when presented with a flood of text,
> > > > but I don't know how or why it works like it works.
> > >
> > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > > doing it synchronously.
> >
> > Hopefully only the parts of the screen which need a redraw?
> >
> > Not all displays can be updated that fast. For a "modern" example, see
> > https://patchwork.freedesktop.org/series/93070/.
>
> drm does damage tracking throughout the stack, e.g.
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties
>
> And unlike fbdev, it's explicit (so less overhead since userspace
> generally knows what it's drawn) and doesn't rely on page fault
> intercepting and fun stuff like that.

My reply was to a paragraph about rendering text by fbcon, not about
userspace rendering graphics.

> Like do people actually know what drm can and cannot do, or would that
> take out all the fun?

;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > > Sven Schnelle <svens@stackframe.org> wrote:
> > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > > blitting' point. I think if that would be the case, no-one would care
> > > > > about 2D acceleration.
> > > >
> > > > I think that is an extremely unfair comparison, because a graphical
> > > > terminal app is not going to render every line of text streamed to it.
> > > > It probably renders only the final view alone if you simply run
> > > > 'dmesg', skipping the first 800-900 lines completely.
> > >
> > > Probably more like "render on every vblank", but yes, unlike fbcon it
> > > surely wouldn't render every single character sent to the terminal.
> > >
> > > Also acceleration on modern hardware is more like "compose window
> > > content using the 3d engine" than "use 2d blitter to scroll the window".
> > >
> > > > Maybe fbcon should do the same when presented with a flood of text,
> > > > but I don't know how or why it works like it works.
> > >
> > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > > doing it synchronously.
> >
> > Hopefully only the parts of the screen which need a redraw?
> >
> > Not all displays can be updated that fast. For a "modern" example, see
> > https://patchwork.freedesktop.org/series/93070/.
>
> drm does damage tracking throughout the stack, e.g.
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties
>
> And unlike fbdev, it's explicit (so less overhead since userspace
> generally knows what it's drawn) and doesn't rely on page fault
> intercepting and fun stuff like that.

My reply was to a paragraph about rendering text by fbcon, not about
userspace rendering graphics.

> Like do people actually know what drm can and cannot do, or would that
> take out all the fun?

;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Thu, Jan 20, 2022 at 1:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > > > Sven Schnelle <svens@stackframe.org> wrote:
> > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > > > blitting' point. I think if that would be the case, no-one would care
> > > > > > about 2D acceleration.
> > > > >
> > > > > I think that is an extremely unfair comparison, because a graphical
> > > > > terminal app is not going to render every line of text streamed to it.
> > > > > It probably renders only the final view alone if you simply run
> > > > > 'dmesg', skipping the first 800-900 lines completely.
> > > >
> > > > Probably more like "render on every vblank", but yes, unlike fbcon it
> > > > surely wouldn't render every single character sent to the terminal.
> > > >
> > > > Also acceleration on modern hardware is more like "compose window
> > > > content using the 3d engine" than "use 2d blitter to scroll the window".
> > > >
> > > > > Maybe fbcon should do the same when presented with a flood of text,
> > > > > but I don't know how or why it works like it works.
> > > >
> > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > > > doing it synchronously.
> > >
> > > Hopefully only the parts of the screen which need a redraw?
> > >
> > > Not all displays can be updated that fast. For a "modern" example, see
> > > https://patchwork.freedesktop.org/series/93070/.
> >
> > drm does damage tracking throughout the stack, e.g.
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties
> >
> > And unlike fbdev, it's explicit (so less overhead since userspace
> > generally knows what it's drawn) and doesn't rely on page fault
> > intercepting and fun stuff like that.
>
> My reply was to a paragraph about rendering text by fbcon, not about
> userspace rendering graphics.

Yeah, and ofc when I say "throughout the stack" this also includes the
fbdev emulation, including the mmap intercepting with fbdev_defio and
all that. They all get remapped to that damage tracking property,
which drivers can then inspect using a bunch of helpers.

But reading code&docs is too hard I guess, safer to assume it's just
broken and not supported.
-Daniel

> > Like do people actually know what drm can and cannot do, or would that
> > take out all the fun?
>
> ;-)
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Thu, Jan 20, 2022 at 1:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > > > Sven Schnelle <svens@stackframe.org> wrote:
> > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > > > blitting' point. I think if that would be the case, no-one would care
> > > > > > about 2D acceleration.
> > > > >
> > > > > I think that is an extremely unfair comparison, because a graphical
> > > > > terminal app is not going to render every line of text streamed to it.
> > > > > It probably renders only the final view alone if you simply run
> > > > > 'dmesg', skipping the first 800-900 lines completely.
> > > >
> > > > Probably more like "render on every vblank", but yes, unlike fbcon it
> > > > surely wouldn't render every single character sent to the terminal.
> > > >
> > > > Also acceleration on modern hardware is more like "compose window
> > > > content using the 3d engine" than "use 2d blitter to scroll the window".
> > > >
> > > > > Maybe fbcon should do the same when presented with a flood of text,
> > > > > but I don't know how or why it works like it works.
> > > >
> > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > > > doing it synchronously.
> > >
> > > Hopefully only the parts of the screen which need a redraw?
> > >
> > > Not all displays can be updated that fast. For a "modern" example, see
> > > https://patchwork.freedesktop.org/series/93070/.
> >
> > drm does damage tracking throughout the stack, e.g.
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties
> >
> > And unlike fbdev, it's explicit (so less overhead since userspace
> > generally knows what it's drawn) and doesn't rely on page fault
> > intercepting and fun stuff like that.
>
> My reply was to a paragraph about rendering text by fbcon, not about
> userspace rendering graphics.

Yeah, and ofc when I say "throughout the stack" this also includes the
fbdev emulation, including the mmap intercepting with fbdev_defio and
all that. They all get remapped to that damage tracking property,
which drivers can then inspect using a bunch of helpers.

But reading code&docs is too hard I guess, safer to assume it's just
broken and not supported.
-Daniel

> > Like do people actually know what drm can and cannot do, or would that
> > take out all the fun?
>
> ;-)
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jan 20, 2022 at 1:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
> > > <geert@linux-m68k.org> wrote:
> > > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > > > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > > > > Sven Schnelle <svens@stackframe.org> wrote:
> > > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > > > > blitting' point. I think if that would be the case, no-one would care
> > > > > > > about 2D acceleration.
> > > > > >
> > > > > > I think that is an extremely unfair comparison, because a graphical
> > > > > > terminal app is not going to render every line of text streamed to it.
> > > > > > It probably renders only the final view alone if you simply run
> > > > > > 'dmesg', skipping the first 800-900 lines completely.
> > > > >
> > > > > Probably more like "render on every vblank", but yes, unlike fbcon it
> > > > > surely wouldn't render every single character sent to the terminal.
> > > > >
> > > > > Also acceleration on modern hardware is more like "compose window
> > > > > content using the 3d engine" than "use 2d blitter to scroll the window".
> > > > >
> > > > > > Maybe fbcon should do the same when presented with a flood of text,
> > > > > > but I don't know how or why it works like it works.
> > > > >
> > > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > > > > doing it synchronously.
> > > >
> > > > Hopefully only the parts of the screen which need a redraw?
> > > >
> > > > Not all displays can be updated that fast. For a "modern" example, see
> > > > https://patchwork.freedesktop.org/series/93070/.
> > >
> > > drm does damage tracking throughout the stack, e.g.
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties
> > >
> > > And unlike fbdev, it's explicit (so less overhead since userspace
> > > generally knows what it's drawn) and doesn't rely on page fault
> > > intercepting and fun stuff like that.
> >
> > My reply was to a paragraph about rendering text by fbcon, not about
> > userspace rendering graphics.
>
> Yeah, and ofc when I say "throughout the stack" this also includes the
> fbdev emulation, including the mmap intercepting with fbdev_defio and
> all that. They all get remapped to that damage tracking property,
> which drivers can then inspect using a bunch of helpers.

And I really meant the text rendering part, not the copy of the shadow
buffer after the rendering.

> But reading code&docs is too hard I guess, safer to assume it's just
> broken and not supported.

Don't worry, I'm actually writing a larger rebuttal _and_ code...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jan 20, 2022 at 1:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven
> > > <geert@linux-m68k.org> wrote:
> > > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote:
> > > > > > On Mon, 17 Jan 2022 19:47:39 +0100
> > > > > > Sven Schnelle <svens@stackframe.org> wrote:
> > > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> > > > > > > a dmesg with 919 lines one the text console took about 2s to display. In
> > > > > > > x11, i measure 22ms. This might be unfair because encoding might be
> > > > > > > different, but i cannot confirm the 'memcpy' is faster than hardware
> > > > > > > blitting' point. I think if that would be the case, no-one would care
> > > > > > > about 2D acceleration.
> > > > > >
> > > > > > I think that is an extremely unfair comparison, because a graphical
> > > > > > terminal app is not going to render every line of text streamed to it.
> > > > > > It probably renders only the final view alone if you simply run
> > > > > > 'dmesg', skipping the first 800-900 lines completely.
> > > > >
> > > > > Probably more like "render on every vblank", but yes, unlike fbcon it
> > > > > surely wouldn't render every single character sent to the terminal.
> > > > >
> > > > > Also acceleration on modern hardware is more like "compose window
> > > > > content using the 3d engine" than "use 2d blitter to scroll the window".
> > > > >
> > > > > > Maybe fbcon should do the same when presented with a flood of text,
> > > > > > but I don't know how or why it works like it works.
> > > > >
> > > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > > > > doing it synchronously.
> > > >
> > > > Hopefully only the parts of the screen which need a redraw?
> > > >
> > > > Not all displays can be updated that fast. For a "modern" example, see
> > > > https://patchwork.freedesktop.org/series/93070/.
> > >
> > > drm does damage tracking throughout the stack, e.g.
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties
> > >
> > > And unlike fbdev, it's explicit (so less overhead since userspace
> > > generally knows what it's drawn) and doesn't rely on page fault
> > > intercepting and fun stuff like that.
> >
> > My reply was to a paragraph about rendering text by fbcon, not about
> > userspace rendering graphics.
>
> Yeah, and ofc when I say "throughout the stack" this also includes the
> fbdev emulation, including the mmap intercepting with fbdev_defio and
> all that. They all get remapped to that damage tracking property,
> which drivers can then inspect using a bunch of helpers.

And I really meant the text rendering part, not the copy of the shadow
buffer after the rendering.

> But reading code&docs is too hard I guess, safer to assume it's just
> broken and not supported.

Don't worry, I'm actually writing a larger rebuttal _and_ code...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> But reading code&docs is too hard I guess, safer to assume it's just
> broken and not supported.

I confirm there's lots of documentation (and even more code ;-),
which is always great!
But both are intimidating to me, and most of the documentation covers
features I'm not interested in, as they're only applicable to fancy
modern truecolor 3D-capable multi-buffer and multi-head hardware, while
what I am looking for is usually not documented.  E.g. I had a hard
time to discover how color look-up tables work (gamma_{store,size}!),
as this is not covered in https://docs.kernel.org/gpu/index.html,
and none of the tinydrm drivers support CLUT modes.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> But reading code&docs is too hard I guess, safer to assume it's just
> broken and not supported.

I confirm there's lots of documentation (and even more code ;-),
which is always great!
But both are intimidating to me, and most of the documentation covers
features I'm not interested in, as they're only applicable to fancy
modern truecolor 3D-capable multi-buffer and multi-head hardware, while
what I am looking for is usually not documented.  E.g. I had a hard
time to discover how color look-up tables work (gamma_{store,size}!),
as this is not covered in https://docs.kernel.org/gpu/index.html,
and none of the tinydrm drivers support CLUT modes.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 24, 2022 at 7:51 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > But reading code&docs is too hard I guess, safer to assume it's just
> > broken and not supported.
>
> I confirm there's lots of documentation (and even more code ;-),
> which is always great!
> But both are intimidating to me, and most of the documentation covers
> features I'm not interested in, as they're only applicable to fancy
> modern truecolor 3D-capable multi-buffer and multi-head hardware, while
> what I am looking for is usually not documented.  E.g. I had a hard
> time to discover how color look-up tables work (gamma_{store,size}!),
> as this is not covered in https://docs.kernel.org/gpu/index.html,
> and none of the tinydrm drivers support CLUT modes.

Hm yeah that part is a bit awkward since due to how Xorg works here
the gamma table is abused to be the lookup table for C8. If we're
adding piles of new Cx formats it might be worth it to structure this
a bit better, e.g. (really just thinking on the spot here):
- have a separate Cx lookup table blob in drm_plane_state (in theory
you could have a different one on each plane and still have an overall
gamma ramp on the crtc)
- change the compat functions which map the legacy gamma ramp to
redirect to the plane gamma ramp if the primary plane is set to Cx
- bonus points for then correctly sizing the lookup table to match the
number of bits in the Cx plane format

But unfiddling this confusion properly is going to be tricky. I think
just continuing the tradition we have for C8 and reusing the crtc
gamma ramp for that is probably fine for now.

And yes that's not documented, because when we fixed the docs for the
entire degamm/CGM/gamma color correction pipeline Cx wasn't the top
priority :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 24, 2022 at 7:51 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > But reading code&docs is too hard I guess, safer to assume it's just
> > broken and not supported.
>
> I confirm there's lots of documentation (and even more code ;-),
> which is always great!
> But both are intimidating to me, and most of the documentation covers
> features I'm not interested in, as they're only applicable to fancy
> modern truecolor 3D-capable multi-buffer and multi-head hardware, while
> what I am looking for is usually not documented.  E.g. I had a hard
> time to discover how color look-up tables work (gamma_{store,size}!),
> as this is not covered in https://docs.kernel.org/gpu/index.html,
> and none of the tinydrm drivers support CLUT modes.

Hm yeah that part is a bit awkward since due to how Xorg works here
the gamma table is abused to be the lookup table for C8. If we're
adding piles of new Cx formats it might be worth it to structure this
a bit better, e.g. (really just thinking on the spot here):
- have a separate Cx lookup table blob in drm_plane_state (in theory
you could have a different one on each plane and still have an overall
gamma ramp on the crtc)
- change the compat functions which map the legacy gamma ramp to
redirect to the plane gamma ramp if the primary plane is set to Cx
- bonus points for then correctly sizing the lookup table to match the
number of bits in the Cx plane format

But unfiddling this confusion properly is going to be tricky. I think
just continuing the tradition we have for C8 and reusing the crtc
gamma ramp for that is probably fine for now.

And yes that's not documented, because when we fixed the docs for the
entire degamm/CGM/gamma color correction pipeline Cx wasn't the top
priority :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
> 
> Hopefully only the parts of the screen which need a redraw?

Sure.  drm fbdev emulation with shadow framebuffer tracks changes and
only flushes dirty areas to the real framebuffer.

fbcon could do the same when implementing lazy rendering, keeping track
of the chars/attrs which did actually change and only render those to
the (emulated or real) fbdev.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

  Hi,

> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
> 
> Hopefully only the parts of the screen which need a redraw?

Sure.  drm fbdev emulation with shadow framebuffer tracks changes and
only flushes dirty areas to the real framebuffer.

fbcon could do the same when implementing lazy rendering, keeping track
of the chars/attrs which did actually change and only render those to
the (emulated or real) fbdev.

take care,
  Gerd

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Michel Dänzer]

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

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Sven Schnelle]

Hi Michel,

Michel Dänzer <michel.daenzer@mailbox.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

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Sven Schnelle]

Hi Michel,

Michel Dänzer <michel.daenzer@mailbox.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

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 5730 bytes --]

Hi

Am 17.01.22 um 19:47 schrieb Sven Schnelle:
> Hi Thomas,
> 
> Thomas Zimmermann <tzimmermann@suse.de> writes:
> 
>> Hi
>>
>> Am 14.01.22 um 19:11 schrieb Helge Deller:
>>> The fbdev layer is orphaned, but seems to need some care.
>>> So I'd like to step up as new maintainer.
>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> First of all, thank you for stepping up to maintain the fbdev
>> codebase. It really needs someone actively looking after it.
>>
>> And now comes the BUT.
>>
>> I want to second everything said by Danial and Javier. In addition to
>> purely organizational topics (trees, PRs, etc), there are a number of
>> inherit problems with fbdev.
>>
>>   * It's 90s technology. Neither does it fit today's userspace, not
>>     hardware. If you have more than just the most trivial of graphical
>>     output fbdev isn't for you.
>>
>>   * 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

And that is caused by the fact that fbdev is nowhere up to todays 
requirements.

> fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last
> year which was rejected for inclusion into fbdev[1].

Yep, I was hoping for a reply.

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

I didn't say that we're not going to support it at all. It's just not 
supported at the momont. vmwgfx has modesetting code that can serve as 
starting point.

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

For comparison, how fast is fbdev with plain memcpy() and memset()?


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

IIRC the hardware only supported 8-bit palette colors, so C8 was the 
correct choice. Otherwise, you can add new formats and add them to the 
console.

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

I admit that your hardware is at the edge of what DRM currently 
supports. But I've used some of the DRM stuff on Athlon XPs with PCI 
graphics. While the performance wasn't good, it was far from unusable.

I guess you used GEM SHMEM for memory buffers. fbdev and mmap with shmem 
pages use some of the same bits in struct page, so shmem cannot mmap 
it's pages directly. We have to use an additional shadow buffer. Any 
display update goes from the shadow buffer into the shmem buffer and 
into the videoram. That's two memcpys. This can be reduced to one 
memcpy, but we never had the requirement to do so.

There's also potential for reducing the amount of page 
mappings/unmappings with gem shmem.

And DRM supports shadow buffers, virtual screen sizes and damage 
handling in DRM. A sophisticated driver might be able to use shadow 
buffering, damage handling and hardware panning to reduce the amount of 
screen updates to a minimum.

Until these things are fixed, adding hardware blitting doesn't really 
make sense IMHO.

As with other things, we didn't have a requirement for all these 
optimizations so far. A usually good approach to improve the sitution is 
to get a basic driver merged and then address the problems one by one.

Best regards
Thomas



> 
> I also tested the speed on my Thinkpad X1 with Intel graphics, and there
> a dmesg with 919 lines one the text console took about 2s to display. In
> x11, i measure 22ms. This might be unfair because encoding might be
> different, but i cannot confirm the 'memcpy' is faster than hardware
> blitting' point. I think if that would be the case, no-one would care
> about 2D acceleration.
> 
> Don't get me wrong, i'm not saying there's no reason for DRM. I fully
> understand why it exists and think it's a good way to go. But for system
> where a (fast) local console is required without X11, fbdev might be the
> better choice at the moment.
> 
> Regards
> Sven
> 
> [1] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m57cdea83608fc78bfc6c2e76eb037bf82017b302
> [2] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m46a52815036a958f6a11d2f3f62e1340a09bd981
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]