Messages in this thread | | | Date | Mon, 17 Jan 2022 17:05:21 +0100 | Subject | Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer | From | 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 >>> >> >
| |