Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751868AbdHCPSu (ORCPT ); Thu, 3 Aug 2017 11:18:50 -0400 Received: from vern.gendns.com ([206.190.152.46]:51263 "EHLO vern.gendns.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751154AbdHCPSs (ORCPT ); Thu, 3 Aug 2017 11:18:48 -0400 Subject: Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display To: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org Cc: David Airlie , Rob Herring , Mark Rutland , Sekhar Nori , Kevin Hilman , linux-fbdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Daniel Vetter References: <1501355870-13960-1-git-send-email-david@lechnology.com> <5d8f6518-8d7e-c029-2da4-e3417afb3e40@lechnology.com> <28188f5c-1daf-121b-6daf-1899668c3875@tronnes.org> <1ce36d43-b9dd-807e-23aa-bac4fda70fdc@lechnology.com> From: David Lechner Message-ID: Date: Thu, 3 Aug 2017 10:18:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4914 Lines: 123 On 08/03/2017 09:07 AM, Noralf Trønnes wrote: > > Den 02.08.2017 00.26, skrev David Lechner: >> On 08/01/2017 01:08 PM, Noralf Trønnes wrote: >>> (cc: Daniel Vetter) >>> >>> >>> Den 01.08.2017 18.51, skrev David Lechner: >>>> On 07/30/2017 12:14 PM, Noralf Trønnes wrote: >>>>> >>>>> Den 29.07.2017 21.40, skrev David Lechner: >>>>>> On 07/29/2017 02:17 PM, David Lechner wrote: >>>>>>> The goal of this series is to get the built-in LCD of the LEGO >>>>>>> MINDSTORMS EV3 >>>>>>> working. But, most of the content here is building up the >>>>>>> infrastructure to do >>>>>>> that. >>>>>>> >>>>>> >>>>>> Some general comments/questions: >>>>>> >>>>>> I have noticed that DRM doesn't really have support for monochrome >>>>>> displays. I'm guessing that is because no one really uses them >>>>>> anymore? >>>>>> >>>>> >>>>> The repaper driver was the first monochrome drm driver and I chose to >>>>> present it to userspace as XRGB8888 and convert it to monochrome. >>>>> The reason for this is that everything, libraries, apps, plymouth >>>>> (boot >>>>> splash, no rgb565) supports it. I didn't see any point in adding a new >>>>> monochrome drm format that didn't have, or probably wouldn't get >>>>> userspace support (by libraries at least). The application of course >>>>> needs to know this to get a good result. >>>>> >>>>> tinydrm_xrgb8888_to_gray8() does the conversion: >>>>> https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781 >>>>> >>>>> >>>>>> The LEGO EV3 display is just an LCD (not the backlit kind). It has >>>>>> two modes of operation. It can to 2bbp grayscale or it can do 1bpp >>>>>> monochrome. The grayscale isn't the best (looks splotchy in >>>>>> places), so it would be nice to be able to choose between these >>>>>> two modes. How would I implement something like that? >>>>>> >>>>> >>>>> Do you expect anyone to use grayscale if it doesn't look good? >>>>> Maybe better to add it later if there's a demand for it. >>>> >>>> I don't expect many people to use it at all. The people that do will >>>> be hackers like me that want to see what it is capable of, so I >>>> think I will keep it grayscale by default. >>>> >>> >>> It looks like the best way to satisfy your needs is to add specific >>> formats. >>> >>> Video for Linux have these: >>> >>> include/uapi/linux/videodev2.h >>> >>> /* Grey formats */ >>> #define V4L2_PIX_FMT_GREY v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 >>> Greyscale */ >>> #define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 >>> Greyscale */ >>> #define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6 >>> Greyscale */ >>> #define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 >>> Greyscale */ >>> #define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12 >>> Greyscale */ >>> #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 >>> Greyscale */ >>> #define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16 >>> Greyscale BE */ >>> >>> >>> Maybe we can add formats like these: >>> >>> include/uapi/drm/drm_fourcc.h >>> >>> #define DRM_FORMAT_MONO fourcc_code('Y', '0', '1', ' ') /* [0] >>> Monochrome */ >>> or >>> #define DRM_FORMAT_Y1 fourcc_code('Y', '0', '1', ' ') /* [0] >>> Monochrome */ >>> >>> #define DRM_FORMAT_Y2 fourcc_code('Y', '0', '2', ' ') /* [1:0] >>> Greyscale */ >>> >>> Daniel, what do you think? >> >> 2 of the first 3 tinydrm drivers are monochrome (and I would like to >> write a driver for the Seeed/Grove I2C OLED displays which are also >> monochrome), so I think the 1bpp modes would definitely be useful. > > David, I'm curious about those displays what controller/interface they use. > I have been hoping that it would be possible to use regmap as an > abstraction for many of these controllers and their registers. The particular display I have is this one: http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/ It looks like it uses a command/data scheme like the MIPI displays, but doesn't use any of the standard values for the commands. The controller can do parallel, SPI and I2C, but the display I have is wired for I2C. > > For MIPI DCS it wasn't possible because it's command oriented with > arguments. Since zero arguments is possible, a register with no value > is nonsense, even though the regmap implementation happily let me do it. > There's also the problem that regmap doesn't support registers with > different widths. Which is a problem if all registers are 8-bit wide, > except the GRAM register being 16-bit on RGB565 formats. > > regmap is especially helpful with controllers that also have > gpios/keypad/touch/pwm, since the mfd (multi function device) subsystem > has good support for sharing regmaps between drivers. Multi function > devices are split into several drivers. > > Noralf. >