Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

From: Daniel Vetter
Date: Thu Aug 03 2017 - 06:05:39 EST


On Wed, Aug 02, 2017 at 11:05:58AM -0500, David Lechner wrote:
> 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.

That probably means we'd need to extend fbdev emulation helpers in drm to
support Monochrome modes better. Shouldn't be that much work really.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch