From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CDFC6C43219 for ; Thu, 21 Apr 2022 06:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=09jumkbjVDPraoTaS7CVbhfE17fiKXcQ1CLm0kRRJ0A=; b=nW84qe+AB0vDZ7 S7Evq15JIZ7G2BXAp77KJaPhmdn+GDHKudGbQwevONzLHDFuahBySgtgi03g78jYAjzEPiTebYcw4 nZrFn2yFGbDPX5X4oPk51RqsyDPHo1JasiNhfkcXiMmDIT7+X2MAZR96uiXAckaeToTYppE5FFjaa bhQ6dAUkiSxiBGQvKdF7mFNC9zWD7z7z6+geXCoH5BCLqhB8Q9qC3K21KCVNTKYN5S0Yo/0XAQNDp w/6ZdF4H1TnS/9r/BvPsfUodYNG0BOM1wRe8URK25TUSBmo6Nz98Pka85WWX2C/ahDhWJfZhTmL2a ns3atPtGIUsKkrWFlAmg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhQY6-00BoS4-27; Thu, 21 Apr 2022 06:44:19 +0000 Received: from mail.andi.de1.cc ([2a01:238:4321:8900:456f:ecd6:43e:202c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhQXl-00BoHg-OW; Thu, 21 Apr 2022 06:43:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kemnade.info; s=20180802; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xkg/9fBx91D98nGOM7iMUznlEWdi4zGYGgMCknbS6fg=; b=HhAjS2WKe9oB9WWs9KZtnCFVXr C1N/qwuSD8n5GT+YN72L1mkOrQl9ENF0LWI38XgbUSgUXGIQS2kOLp8/3vloH4sZOeLoiUfHWWSNz c+kOjPTQbRAwailjS/Ma3fUu1rRgd6z4ySOdlIUtXvK6yEDscEO8f04w3y/UlZdp0BT4=; Received: from p200300ccff1491001a3da2fffebfd33a.dip0.t-ipconnect.de ([2003:cc:ff14:9100:1a3d:a2ff:febf:d33a] helo=aktux) by mail.andi.de1.cc with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1nhQXU-0002cN-3m; Thu, 21 Apr 2022 08:43:40 +0200 Date: Thu, 21 Apr 2022 08:43:38 +0200 From: Andreas Kemnade To: Samuel Holland Cc: Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Sandy Huang , dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, Alistair Francis , =?UTF-8?B?T25kxZllag==?= Jirman , Daniel Vetter , David Airlie , Geert Uytterhoeven , Krzysztof Kozlowski , Liang Chen , Maarten Lankhorst , Maxime Ripard , Michael Riesch , Nicolas Frattaroli , Peter Geis , Rob Herring , Sam Ravnborg , Thierry Reding , Thomas Zimmermann , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver Message-ID: <20220421084338.084c4d6e@aktux> In-Reply-To: <20220413221916.50995-1-samuel@sholland.org> References: <20220413221916.50995-1-samuel@sholland.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220420_234357_982788_34FB3B42 X-CRM114-Status: GOOD ( 23.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 13 Apr 2022 17:19:00 -0500 Samuel Holland wrote: [...] > Waveform Selection From Userspace > ================================= > EPDs use different waveforms for different purposes: high-quality > grayscale vs. monochrome text vs. dithered monochrome video. How can > userspace select which waveform to use? Should this be a plane property? > Or does userspace rather select a QoS, like low-latency vs. high quality. Or this will not change for a longer time: like doing full refreshes. > It is also likely that userspace will want to use different waveforms at > the same time for different parts of the screen, for example a fast > monochrome waveform for the drawing area of a note-taking app, but a > grayscale waveform for surrounding UI and window manager. > > I believe the i.MX6 EPDC supports multiple planes, each with their own > waveform choice. That seems like a good abstraction, but the EBC only > supports one plane in hardware. So using this abstraction with the EBC > would require blending pixels and doing waveform lookups in software. > The iMX6 EPDC has one working buffer containing the old+new state of the pixel. That is 16bpp. Then for each update you can specify a rectangle in an independant 8bpp buffer as a source. For now I am just using a single buffer. But yes, that construction could be used to do some multi plane stuff. > Blitting/Blending in Software > ============================= > There are multiple layers to this topic (pun slightly intended): > 1) Today's userspace does not expect a grayscale framebuffer. > Currently, the driver advertises XRGB8888 and converts to Y4 > in software. This seems to match other drivers (e.g. repaper). > > 2) Ignoring what userspace "wants", the closest existing format is > DRM_FORMAT_R8. Geert sent a series[4] adding DRM_FORMAT_R1 through > DRM_FORMAT_R4 (patch 9), which I believe are the "correct" formats > to use. > hmm R=red? That sounds strange. I am unsure whether doing things with lower bit depths actually really helps. > 3) The RK356x SoCs have an "RGA" hardware block that can do the > RGB-to-grayscale conversion, and also RGB-to-dithered-monochrome > which is needed for animation/video. Currently this is exposed with > a V4L2 platform driver. Can this be inserted into the pipeline in a > way that is transparent to userspace? Or must some userspace library > be responsible for setting up the RGA => EBC pipeline? hmm, we have other drivers with some hardware block doing rotation, but in that cases it is not exposed as v4l2 mem2mem device. On IMX6 there is also the PXP doing RGB-to-grayscale and rotation but exposed as v4l2 device. But it can also be used to do undocumented stuff writing to the 16bpp working buffer. So basically it is similar. But I would do thoso things in a second step and just have the basic stuff upstreamed Regards, Andreas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel