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@xxxxxxxxxxxxxx >>> >>> 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 >>> >> >
