From: David Lechner <david@lechnology.com>
To: "Noralf Trønnes" <noralf@tronnes.org>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
"Daniel Vetter" <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>, Sekhar Nori <nsekhar@ti.com>,
Kevin Hilman <khilman@kernel.org>,
linux-fbdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display
Date: Wed, 2 Aug 2017 11:05:58 -0500 [thread overview]
Message-ID: <abbd75ac-67f6-e189-5093-ee4a8f44ba6e@lechnology.com> (raw)
In-Reply-To: <937aa71c-1415-4645-7e04-6be43dd33174@tronnes.org>
On 08/02/2017 03:05 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. I
>> think there is enough userspace code still around that knows about
>> FB_VISUAL_MONO01 and FB_VISUAL_MONO10 that could use these.
>>
>
> Can you elaborate, would you use the display trough monochrome fbdev
> or through drm?
I have a small collection of programs and libraries that work using
monochrome fbdev. I would like to just keep using them without having to
convert everything to drm.
>> I don't think a Y02 mode would be useful though. There is pretty much
>> nothing out there (that I could find) that uses such a mode.
>>
>> A Y08 mode for 8bpp grayscale would be useful though. This is another
>> more commonly used format.
>>
>
> Another source of fourcc's is FFmpeg which has these:
>
> { AV_PIX_FMT_GRAY8, MKTAG('Y', '8', '0', '0') },
> { AV_PIX_FMT_GRAY8, MKTAG('Y', '8', ' ', ' ') },
> { AV_PIX_FMT_GRAY8, MKTAG('G', 'R', 'E', 'Y') },
>
> { AV_PIX_FMT_MONOWHITE,MKTAG('B', '1', 'W', '0') },
> { AV_PIX_FMT_MONOBLACK,MKTAG('B', '0', 'W', '1') },
>
> AV_PIX_FMT_GRAY8
> Y , 8bpp.
> AV_PIX_FMT_MONOWHITE
> Y , 1bpp, 0 is white, 1 is black,
> in each byte pixels are ordered from the msb to the lsb.
> AV_PIX_FMT_MONOBLACK
> Y , 1bpp, 0 is black, 1 is white,
> in each byte pixels are ordered from the msb to the lsb.
>
>
> __drm_format_info() provides details about formats:
> { .format = DRM_FORMAT_MONO, .depth = 1, .num_planes = 1, .cpp
> = { 0, 0, 0 }, .hsub = 1, .vsub = 1 },
> { .format = DRM_FORMAT_GREY, .depth = 8, .num_planes = 1, .cpp
> = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
>
> framebuffer_check() and drm_fb_cma_create_with_funcs() use cpp for
> validation and they don't expect it to be zero.
>
>
> Noralf.
>
>>>
>>>>>
>>>>>> Also, how can I indicate to userspace that this display really is
>>>>>> monochrome/grayscale since the reported color depth 16bpp?
>>>>>>
>>>>>
>>>>> There isn't unless we add formats for it.
>>>>> Since this display is in a Lego piece, doesn't it have custom
>>>>> userspace
>>>>> that already know it's monochrome?
>>>>
>>>> The official LEGO software is like this, yes. But I am working on a
>>>> project that supports other LEGO compatible devices that have color
>>>> screens, so the same software needs to be able to detect at runtime
>>>> which type of screen it is using. Currently I have a plain fbdev
>>>> driver that provides FB_VISUAL_MONO10 for the EV3 display and so the
>>>> software knows when it has a monochrome screen and when it doesn't.
>>>> But since plain fbdev drivers can't be accepted into mainline, I
>>>> need to find a different way to detect what type of screen this is
>>>> so that my graphics library can treat it differently.
>>>>
>>>>
>>>
>>> You can tell userspace about the preferred bitdepth:
>>> drm->mode_config.preferred_depth
>>>
>>>
>>> Noralf.
>>>
>>
>
next prev parent reply other threads:[~2017-08-02 16:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-29 19:17 [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display David Lechner
2017-07-29 19:17 ` [PATCH 1/6] drm/tinydrm: Add parameter for MIPI DCS pixel format David Lechner
2017-07-30 18:10 ` Andy Shevchenko
2017-07-29 19:17 ` [PATCH 2/6] drm/tinydrm: add helpers for ST7586 controllers David Lechner
2017-07-30 18:19 ` Andy Shevchenko
2017-07-29 19:17 ` [PATCH 3/6] drm/tinydrm: rename mi028qt module to mipi-panel David Lechner
2017-07-29 19:30 ` David Lechner
2017-07-29 19:17 ` [PATCH 4/6] drm/tinydrm: mipi-panel: refactor to use driver id David Lechner
2017-07-30 18:24 ` Andy Shevchenko
2017-07-29 19:17 ` [PATCH 5/6] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD David Lechner
2017-07-30 18:26 ` Andy Shevchenko
2017-07-29 19:17 ` [PATCH 6/6] ARM: dts: da850-lego-ev3: Add node for LCD display David Lechner
2017-07-29 19:40 ` [PATCH 0/6] Support for LEGO MINDSTORMS EV3 " David Lechner
2017-07-30 17:14 ` Noralf Trønnes
2017-08-01 16:51 ` David Lechner
2017-08-01 18:08 ` Noralf Trønnes
2017-08-01 22:26 ` David Lechner
2017-08-02 8:05 ` Noralf Trønnes
2017-08-02 16:05 ` David Lechner [this message]
2017-08-03 10:05 ` Daniel Vetter
2017-08-03 14:07 ` Noralf Trønnes
2017-08-03 15:18 ` David Lechner
2017-08-03 17:09 ` Andy Shevchenko
2017-08-03 17:11 ` Andy Shevchenko
2017-08-03 20:11 ` Noralf Trønnes
2017-08-04 1:08 ` David Lechner
2017-08-04 1:16 ` David Lechner
2017-07-30 17:12 ` Noralf Trønnes
2017-07-30 18:27 ` Andy Shevchenko
2017-07-30 18:27 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abbd75ac-67f6-e189-5093-ee4a8f44ba6e@lechnology.com \
--to=david@lechnology.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=noralf@tronnes.org \
--cc=nsekhar@ti.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).