Messages in this thread | | | Date | Mon, 17 Jan 2022 14:51:07 +0100 | Subject | Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer | From | Thomas Zimmermann <> |
| |
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 [unhandled content-type:application/pgp-signature] | |