Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1701241 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display David Lechner <david@lechnology.com> - 2017-08-01 19:00 +0200
    Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display Noralf Trønnes <noralf@tronnes.org> - 2017-08-01 20:10 +0200
      Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display David Lechner <david@lechnology.com> - 2017-08-02 00:30 +0200
        Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display Noralf Trønnes <noralf@tronnes.org> - 2017-08-02 10:10 +0200
          Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display David Lechner <david@lechnology.com> - 2017-08-02 18:10 +0200
            Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display Daniel Vetter <daniel@ffwll.ch> - 2017-08-03 12:10 +0200
        Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display Noralf Trønnes <noralf@tronnes.org> - 2017-08-03 16:10 +0200
          Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display David Lechner <david@lechnology.com> - 2017-08-03 17:20 +0200
            Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-08-03 19:10 +0200
              Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-08-03 19:20 +0200
                Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display Noralf Trønnes <noralf@tronnes.org> - 2017-08-03 22:20 +0200
                  Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display David Lechner <david@lechnology.com> - 2017-08-04 03:10 +0200
                    Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display David Lechner <david@lechnology.com> - 2017-08-04 03:20 +0200

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

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.

> 
>> 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.

[toc] | [next] | [standalone]

#1701302

(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?

>>
>>> 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.

[toc] | [prev] | [next] | [standalone]

#1701547

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.

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.

> 
>>>
>>>> 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.
> 

[toc] | [prev] | [next] | [standalone]

#1701823

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 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.
>>
>

[toc] | [prev] | [next] | [standalone]

#1702229

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.
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#1702879

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

[toc] | [prev] | [next] | [standalone]

#1703151

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.

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.

[toc] | [prev] | [next] | [standalone]

#1703187

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.
> 

[toc] | [prev] | [next] | [standalone]

#1703282

On Thu, Aug 3, 2017 at 6:18 PM, David Lechner <david@lechnology.com> wrote:

> 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.

It looks very similar to ssd1306. Some description refers to ssd1308.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1703292

On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Aug 3, 2017 at 6:18 PM, David Lechner <david@lechnology.com> wrote:
>
>> 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.
>
> It looks very similar to ssd1306. Some description refers to ssd1308.

http://www.mouser.com/catalog/specsheets/Seeed_104030008.pdf


-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1703402

Den 03.08.2017 19.11, skrev Andy Shevchenko:
> On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Thu, Aug 3, 2017 at 6:18 PM, David Lechner <david@lechnology.com> wrote:
>>
>>> 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.
>> It looks very similar to ssd1306. Some description refers to ssd1308.
> http://www.mouser.com/catalog/specsheets/Seeed_104030008.pdf
>

That pdf refers to another one: 
http://wiki.seeed.cc/Grove-OLED_Display_0.96inch/
There's an fbdev driver that supports ssd1305, ssd1306, ssd1307 and ssd1309:
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/ssd1307fb.txt
http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/ssd1307fb.c
Maybe the ssd1308 will work with that driver...

Noralf.

[toc] | [prev] | [next] | [standalone]

#1703573

On 08/03/2017 03:11 PM, Noralf Trønnes wrote:
> 
> Den 03.08.2017 19.11, skrev Andy Shevchenko:
>> On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>> On Thu, Aug 3, 2017 at 6:18 PM, David Lechner <david@lechnology.com> 
>>> wrote:
>>>
>>>> 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.
>>> It looks very similar to ssd1306. Some description refers to ssd1308.
>> http://www.mouser.com/catalog/specsheets/Seeed_104030008.pdf
>>
> 
> That pdf refers to another one: 
> http://wiki.seeed.cc/Grove-OLED_Display_0.96inch/
> There's an fbdev driver that supports ssd1305, ssd1306, ssd1307 and 
> ssd1309:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/display/ssd1307fb.txt 
> 
> http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/ssd1307fb.c 
> 
> Maybe the ssd1308 will work with that driver...
> 

The display I have uses a ssd1327 controller. It is 16-bit grayscale. 
The ssd130x are all 1-bit monochrome. So, probably more like the ssd1325 
driver in fbftf.

[toc] | [prev] | [next] | [standalone]

#1703576

On 08/03/2017 08:08 PM, David Lechner wrote:
> On 08/03/2017 03:11 PM, Noralf Trønnes wrote:
>>
>> Den 03.08.2017 19.11, skrev Andy Shevchenko:
>>> On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko
>>> <andy.shevchenko@gmail.com> wrote:
>>>> On Thu, Aug 3, 2017 at 6:18 PM, David Lechner <david@lechnology.com> 
>>>> wrote:
>>>>
>>>>> 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.
>>>> It looks very similar to ssd1306. Some description refers to ssd1308.
>>> http://www.mouser.com/catalog/specsheets/Seeed_104030008.pdf
>>>
>>
>> That pdf refers to another one: 
>> http://wiki.seeed.cc/Grove-OLED_Display_0.96inch/
>> There's an fbdev driver that supports ssd1305, ssd1306, ssd1307 and 
>> ssd1309:
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/display/ssd1307fb.txt 
>>
>> http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/ssd1307fb.c 
>>
>> Maybe the ssd1308 will work with that driver...
>>
> 
> The display I have uses a ssd1327 controller. It is 16-bit grayscale. 
> The ssd130x are all 1-bit monochrome. So, probably more like the ssd1325 
> driver in fbftf.

correction, 4-bit grayscale

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web