Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3357262pxb; Mon, 17 Jan 2022 18:29:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJzsZp1BRWbmSz2n1Ow6ui4al+BRxorzne0ufrjuyIFb0w8XBaDza1tHd1P5Im43O6qxCLi6 X-Received: by 2002:a17:90a:7788:: with SMTP id v8mr37313384pjk.216.1642472960853; Mon, 17 Jan 2022 18:29:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642472960; cv=none; d=google.com; s=arc-20160816; b=jbWTIIv/Z9thjZQuXuMICSdhVTV7TMJwPUZSC5b1mMJ26FnkeFb1Xapyp6HnRPPc6B vPH3o6KzWW9g9Cnyj17hticaBCPwHFKXiu8zUefp1s2J3K1Y/5ZbUhjjX2k8WuuPirbJ TtB6/wAbds4SuYTUrBqkwaGuIW7IzNC63cmEXQiVJEhAAhV/vPdiBiC1RVg6Es9jLx/8 tZdRxIwa5Cx0pYnzDwwRscwF29Nb5BEoT42yJSC91EU9PeFEVv+oNFS+U1wDoEONSFmy Z/+sRhOPFgqv5TO08rdyoGc4gMNKhz25Cgi2OpZnO8/Pf4AkJxGJ7I8UyZSwigxP3aNb weVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=IVkUe3uV+8LCxfEyOkwQAxMSTEPLRyMs/0Qx0B4nQCU=; b=vG0FltAEE+KMMuV+mEWGFjD4X12PToV4iMi39T8X6GmZE/ujTFmAn/q/XCYQm25OR9 Ds6VfOHYYgh5Ozo2cNP3ZhJjT3JVz+NgVi44KIBKDp0H81VMgdSxO6BIje84GwO4YPoY VNShgD9keZildQ9jq06W8wWyp1Zl2VTd5eaBSixraiOC9JcPngRhlo/q7mJsdjj5OLgs +1O2qpo/F4DN1MazysvkHQJvgldbE20lvaZAxrr2HLfBDrgFQzXPe4l/1xoQAfrnz0MW ZWlNsB/+jrZx+MrPa99hd0lz6b21Lky5zEbDi1Z+LTvb+KJ8LhqAQvdqNKqMqqOdguiC 7Cvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b4si12227363plg.151.2022.01.17.18.29.08; Mon, 17 Jan 2022 18:29:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234363AbiAQOKO (ORCPT + 99 others); Mon, 17 Jan 2022 09:10:14 -0500 Received: from mail-ua1-f53.google.com ([209.85.222.53]:46844 "EHLO mail-ua1-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230445AbiAQOKN (ORCPT ); Mon, 17 Jan 2022 09:10:13 -0500 Received: by mail-ua1-f53.google.com with SMTP id c36so30514829uae.13; Mon, 17 Jan 2022 06:10:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IVkUe3uV+8LCxfEyOkwQAxMSTEPLRyMs/0Qx0B4nQCU=; b=NU3WzHjZNvmYoqfteQtWZMlr5Mpol057e5ikKlgFF54YUjW9Kes83mRSC7lJcr+rUI CNLd8zhY8vxhpieLc/Zb/rMVnVizRY73AknaNbUrPNdXpUO9R25G/5RupMHRdu1G47S2 HHyOC9PP3IuxAQIw4Z9MhxIp9WWXIkb/VVvmp5TMdb2Z7cpQvcRupPR0PYB2bZHZKliU fVK3AIJJNa0VH6gqpzrVkXY6fa8ihdbrEx8JsaXa/AWnCQH+9eo6/wGL9Tz2niVAcEf+ +3IyVo9WsY4jEMg7hReXTZT2tw2FTQQJpkv6fOooFK+3NFxEq4d2C+xCjlVT2wJc6DcK iBGg== X-Gm-Message-State: AOAM532U+ZELnBdqXXmo1ytDWXGLkGaNYYIkYVINhztvePKMpQ4ItS0W U6d2vEOlGpR+MDsjCf17lIlIYmH5T3Vbtw== X-Received: by 2002:a9f:2105:: with SMTP id 5mr1076798uab.38.1642428612625; Mon, 17 Jan 2022 06:10:12 -0800 (PST) Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com. [209.85.221.182]) by smtp.gmail.com with ESMTPSA id e10sm541227vsa.29.2022.01.17.06.10.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Jan 2022 06:10:12 -0800 (PST) Received: by mail-vk1-f182.google.com with SMTP id n14so9203380vkk.6; Mon, 17 Jan 2022 06:10:11 -0800 (PST) X-Received: by 2002:a1f:2344:: with SMTP id j65mr7794483vkj.7.1642428611448; Mon, 17 Jan 2022 06:10:11 -0800 (PST) MIME-Version: 1.0 References: <20220117125716.yjwxsze35j2ndn2i@sirius.home.kraxel.org> <70530b62-7b3f-db88-7f1a-f89b824e5825@suse.de> In-Reply-To: <70530b62-7b3f-db88-7f1a-f89b824e5825@suse.de> From: Geert Uytterhoeven Date: Mon, 17 Jan 2022 15:10:00 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer To: Thomas Zimmermann Cc: Gerd Hoffmann , Helge Deller , Daniel Vetter , Linus Torvalds , "airlied@gmail.com" , Linux Fbdev development list , Linux Kernel Mailing List , DRI Development , Javier Martinez Canillas Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann wrote: > Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven: > > On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann 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