[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <669792cd-9899-980a-04b1-4ff64886b751@gmx.de>
Date: Mon, 17 Jan 2022 17:05:21 +0100
From: Helge Deller <deller@....de>
To: Thomas Zimmermann <tzimmermann@...e.de>,
Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Gerd Hoffmann <kraxel@...hat.com>, Daniel Vetter <daniel@...ll.ch>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"airlied@...il.com" <airlied@...il.com>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
DRI Development <dri-devel@...ts.freedesktop.org>,
Javier Martinez Canillas <javierm@...hat.com>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
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@...ux-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
>>>
>>
>
Powered by blists - more mailing lists