This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.

Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest
(https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes:

     ./fbtest -f /dev/fb1
    Using drawops cfb32 (32 bpp packed pixels)
    Available visuals:
      Monochrome
      Grayscale 256
      Truecolor 8:8:8:0
    Using visops truecolor
    Running all tests
    test001: PASSED
    test002: PASSED
    test003: PASSED
    test004: PASSED
    test005: PASSED
    test006: PASSED
    test008: PASSED
    test009: PASSED
    test010: PASSED
    Benchmarking... 10x10 squares: 412.99 Mpixels/s
    Benchmarking... 20x20 squares: 857.46 Mpixels/s
    Benchmarking... 50x50 squares: 1593.51 Mpixels/s
    test012: PASSED
    Benchmarking... R5 circles: 237.07 Mpixels/s
    Benchmarking... R10 circles: 501.24 Mpixels/s
    Benchmarking... R25 circles: 947.86 Mpixels/s
    test013: PASSED

Patch #1 adds an I2C connector type since currently there isn't one and
I2C drivers use DRM_MODE_CONNECTOR_Unknown or DRM_MODE_CONNECTOR_VIRTUAL.

Patch #2 adds a drm_fb_gray8_to_mono_reversed() DRM format helper since
most DRM/KMS user-space don't support bpp 1 displays, so drivers expose
a common format that's converted to greyscale and then to monochrome.

Patch #3 adds the driver. The name ssd1307 was used instead of ssd130x
(which would be more accurate) to avoid confusion for users who want to
migrate from the existing ssd1307fb fbdev driver.

Patch #4 just adds a MAINTAINERS entry for this new DRM driver.

Best regards,
Javier


Javier Martinez Canillas (4):
  drm: Add I2C connector type
  drm/format-helper: Add drm_fb_gray8_to_mono_reversed()
  drm/tiny: Add driver for Solomon SSD1307 OLED displays
  MAINTAINERS: Add entry for Solomon SSD1307 OLED displays DRM driver

 MAINTAINERS                         |   7 +
 drivers/gpu/drm/drm_connector.c     |   1 +
 drivers/gpu/drm/drm_format_helper.c |  35 +
 drivers/gpu/drm/tiny/Kconfig        |  12 +
 drivers/gpu/drm/tiny/Makefile       |   1 +
 drivers/gpu/drm/tiny/ssd1307.c      | 976 ++++++++++++++++++++++++++++
 include/drm/drm_format_helper.h     |   2 +
 include/uapi/drm/drm_mode.h         |   1 +
 8 files changed, 1035 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/ssd1307.c

-- 
2.34.1

This driver only advertises XRGB8888 in ssd1307_formats. It would be nice to
expose R8 as well so that user-space can directly produce suitable buffers.
It would also be nice to have some kind of preferred format, so that user-space
knows R8 is preferred over XRGB8888.

On Monday, January 31st, 2022 at 21:36, Simon Ser <contact@emersion.fr> wrote:

> This driver only advertises XRGB8888 in ssd1307_formats. It would be nice to
> expose R8 as well so that user-space can directly produce suitable buffers.
> It would also be nice to have some kind of preferred format, so that user-space
> knows R8 is preferred over XRGB8888.

Hm, since the format used by the hw is actually R1, adding that to drm_fourcc.h
would be even better.

Let me know if you want me to type up any of the user-space bits.

Hello Simon,

Thanks for your feedback.

On 1/31/22 21:39, Simon Ser wrote:
> On Monday, January 31st, 2022 at 21:36, Simon Ser <contact@emersion.fr> wrote:
> 
>> This driver only advertises XRGB8888 in ssd1307_formats. It would be nice to
>> expose R8 as well so that user-space can directly produce suitable buffers.
>> It would also be nice to have some kind of preferred format, so that user-space
>> knows R8 is preferred over XRGB8888.
> 
> Hm, since the format used by the hw is actually R1, adding that to drm_fourcc.h
> would be even better.
> 

Yes, agreed that would be nice. We discussed this already with Thomas and my
suggestion was to land the driver as is, advertising XRGB8888. Which is also
what the other driver using monochrome does (drivers/gpu/drm/tiny/repaper.c):

https://www.spinics.net/lists/dri-devel/msg331328.html

As a follow-up we can wire up al the needed bits to have a DRM/KMS driver that
could expose a R1 format.

> Let me know if you want me to type up any of the user-space bits.
> 

Thanks! I also could help to add the needed support in the user-space stack.

Best reagards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

On Mon, Jan 31, 2022 at 9:39 PM Simon Ser <contact@emersion.fr> wrote:
> On Monday, January 31st, 2022 at 21:36, Simon Ser <contact@emersion.fr> wrote:
>
> > This driver only advertises XRGB8888 in ssd1307_formats. It would be nice to
> > expose R8 as well so that user-space can directly produce suitable buffers.
> > It would also be nice to have some kind of preferred format, so that user-space
> > knows R8 is preferred over XRGB8888.
>
> Hm, since the format used by the hw is actually R1, adding that to drm_fourcc.h
> would be even better.

What's the story with the Rn formats?
The comments say "n bpp Red", while this is a monochrome (even
inverted) display?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> What's the story with the Rn formats?
>
> The comments say "n bpp Red", while this is a monochrome (even
> inverted) display?

I don't think the color matters that much. "Red" was picked just because it was
an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?

Hi Simon,

On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:
> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > What's the story with the Rn formats?
> >
> > The comments say "n bpp Red", while this is a monochrome (even
> > inverted) display?
>
> I don't think the color matters that much. "Red" was picked just because it was
> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?

I'd expect 8-bit grayscale to be Y8 instead.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Hi

Am 01.02.22 um 09:36 schrieb Geert Uytterhoeven:
> Hi Simon,
> 
> On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:
>> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> What's the story with the Rn formats?
>>>
>>> The comments say "n bpp Red", while this is a monochrome (even
>>> inverted) display?
>>
>> I don't think the color matters that much. "Red" was picked just because it was
>> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?
> 
> I'd expect 8-bit grayscale to be Y8 instead.

I like this naming, but DRM_FORMAT_R8 is uapi already. :/ If anything, 
we could add Yn formats in addition to existing Rn formats.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

On Tuesday, February 1st, 2022 at 11:08, Thomas Zimmermann <tzimmermann@suse.de> wrote:

> Am 01.02.22 um 09:36 schrieb Geert Uytterhoeven:
>
> > I'd expect 8-bit grayscale to be Y8 instead.
>
> I like this naming, but DRM_FORMAT_R8 is uapi already. :/ If anything,
> we could add Yn formats in addition to existing Rn formats.

Need to be a bit careful, e.g. Y210 exists and isn't a grayscale format.
This could be confusing.

Hi

Am 01.02.22 um 11:11 schrieb Simon Ser:
> On Tuesday, February 1st, 2022 at 11:08, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> 
>> Am 01.02.22 um 09:36 schrieb Geert Uytterhoeven:
>>
>>> I'd expect 8-bit grayscale to be Y8 instead.
>>
>> I like this naming, but DRM_FORMAT_R8 is uapi already. :/ If anything,
>> we could add Yn formats in addition to existing Rn formats.
> 
> Need to be a bit careful, e.g. Y210 exists and isn't a grayscale format.
> This could be confusing.

Well, ok.  How about 'I' as in 'intensity'? There aren't too many 
drivers supporting this yet. So if we want to find a better name, now's 
the time.

Best regards
Thomas


-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > What's the story with the Rn formats?
> >
> > The comments say "n bpp Red", while this is a monochrome (even
> > inverted) display?
>
> I don't think the color matters that much. "Red" was picked just because it was
> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?

The red comes from gl, where with shaders it really doesn't matter
what meaning you attach to channels, but really just how many you
have. So 2-channel formats are called RxGx, 3-channel RxGxBx,
4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for
interop in general, hence why these exist.

We should probably make a comment that this really isn't a red channel
when used for display it's a greyscale/intensity format. Aside from
that documentation gap I think reusing Rx formats for
greyscale/intensity for display makes perfect sense.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

On 2/1/22 09:38, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:
>>
>> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>
>>> What's the story with the Rn formats?
>>>
>>> The comments say "n bpp Red", while this is a monochrome (even
>>> inverted) display?
>>
>> I don't think the color matters that much. "Red" was picked just because it was
>> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?
> 
> The red comes from gl, where with shaders it really doesn't matter
> what meaning you attach to channels, but really just how many you
> have. So 2-channel formats are called RxGx, 3-channel RxGxBx,
> 4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for
> interop in general, hence why these exist.
> 
> We should probably make a comment that this really isn't a red channel
> when used for display it's a greyscale/intensity format. Aside from
> that documentation gap I think reusing Rx formats for
> greyscale/intensity for display makes perfect sense.
> -Daniel

To sump up the conversation in the #dri-devel channel, these drivers
should support the following formats:

1) Dx (Daniel suggested that for darkness, but inverted mono)
2) Rx (single-channel for grayscale)
3) RxGxBxAx (4-channel fake 32-bpp truecolor)

The format preference will be in that order, so if user-space is able
to use Dx then there won't be a need for any conversion and just the
native format will be used.

If using Rx then only a Rx -> Dx conversion will happen and the last
format will require the less performant RxGxBxAx -> Rx -> Dx path.

But we still need RxGxBxAx as a fallback for compatibility with the
existing user-space, so all this could be done as a follow-up as an
optimization and shouldn't block monochromatic panel drivers IMO.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

On Tue, 1 Feb 2022 10:49:03 +0100
Javier Martinez Canillas <javierm@redhat.com> wrote:

> On 2/1/22 09:38, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:  
> >>
> >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>  
> >>> What's the story with the Rn formats?
> >>>
> >>> The comments say "n bpp Red", while this is a monochrome (even
> >>> inverted) display?  
> >>
> >> I don't think the color matters that much. "Red" was picked just because it was
> >> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?  
> > 
> > The red comes from gl, where with shaders it really doesn't matter
> > what meaning you attach to channels, but really just how many you
> > have. So 2-channel formats are called RxGx, 3-channel RxGxBx,
> > 4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for
> > interop in general, hence why these exist.
> > 
> > We should probably make a comment that this really isn't a red channel
> > when used for display it's a greyscale/intensity format. Aside from
> > that documentation gap I think reusing Rx formats for
> > greyscale/intensity for display makes perfect sense.
> > -Daniel  
> 
> To sump up the conversation in the #dri-devel channel, these drivers
> should support the following formats:
> 
> 1) Dx (Daniel suggested that for darkness, but inverted mono)

Did you consider format C1 instead?

To my understanding, the C formats are paletted, which would also fit
very nicely semantically. You have an enumerated list of pixel values
and each of them produces some arbitrary color on screen. This would
fit e.g. blue/white LCD panels nicely.

The little problem there is the palette.

C8 format is traditionally translated to RGB triplets through GAMMA LUT.
Therefore the display itself is still three-channel, it's just the
framebuffer format that is single-channel. But now, we are dealing
with truly paletted displays. Furthermore, the palette is fixed,
ingrained in the panel hardware.

So we would probably need a new KMS property for the fixed palette of
the panel. What would it be called? Would it be a connector property?

The property would be a read-only blob, an array that maps Cx values to
"colors". How do we represent "colors"? How do we accommodate C1, C2,
C4 and C8 with the same blob?

Since the blob is a mapping from color index to "color", and the array
in the blob has N entries, we could simply say that Cx integer value is
the color index. If the Cx you use does not go up to N, then you miss
some colors. If the Cx you use can go higher than N, then Cx values >=
N will clamp to N-1, for example. Of course, if your panel palette has
only 4 entries, you can expose C1 and C2 and have no reason to expose
C4 or C8, avoiding the Cx >= N issue.

How do we define the array contents then, the "colors"... plain old RGB
triplets do not mean much[1], but that would be better than nothing. I
also suppose that people would not be keen on seeing something like CIE
1931 XYZ or Lab values, even though those would probably have the most
useful definition. Coming up with those values properly would require a
colorimeter. As a compromise, maybe we could use an RGB triplet, and
assume sRGB SDR color space and transfer function, just like we do with
all displays whether they are that or not. If someone needs to know
better, then they can profile the display. sRGB triplets would likely
give enough intuition to what color the indices result in, that it
could be used in automated color conversions or quantizations from
larger color spaces like sRGB with some rough degree of color
similarity.

It is a lot of hassle, but it would have a clear benefit: userspace
would know very well how the display behaves (what colors it shows,
roughly), and you could use Cx formats to drive a panel in its "native"
format.

Possible problems are around interactions with the old GAMMA property,
which is traditionally used for the C8 palette. But if you have a
fixed-palette panel, then maybe you wouldn't expose GAMMA property on
the CRTC at all?

I have no idea how this would map to fbdev API though.


[1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/pixels_color.md

Thanks,
pq


> 2) Rx (single-channel for grayscale)
> 3) RxGxBxAx (4-channel fake 32-bpp truecolor)
> 
> The format preference will be in that order, so if user-space is able
> to use Dx then there won't be a need for any conversion and just the
> native format will be used.
> 
> If using Rx then only a Rx -> Dx conversion will happen and the last
> format will require the less performant RxGxBxAx -> Rx -> Dx path.
> 
> But we still need RxGxBxAx as a fallback for compatibility with the
> existing user-space, so all this could be done as a follow-up as an
> optimization and shouldn't block monochromatic panel drivers IMO.
> 
> Best regards,

Hi Pekka,

On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Tue, 1 Feb 2022 10:49:03 +0100
> Javier Martinez Canillas <javierm@redhat.com> wrote:
> > On 2/1/22 09:38, Daniel Vetter wrote:
> > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:
> > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >>> What's the story with the Rn formats?
> > >>>
> > >>> The comments say "n bpp Red", while this is a monochrome (even
> > >>> inverted) display?
> > >>
> > >> I don't think the color matters that much. "Red" was picked just because it was
> > >> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?
> > >
> > > The red comes from gl, where with shaders it really doesn't matter
> > > what meaning you attach to channels, but really just how many you
> > > have. So 2-channel formats are called RxGx, 3-channel RxGxBx,
> > > 4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for
> > > interop in general, hence why these exist.
> > >
> > > We should probably make a comment that this really isn't a red channel
> > > when used for display it's a greyscale/intensity format. Aside from
> > > that documentation gap I think reusing Rx formats for
> > > greyscale/intensity for display makes perfect sense.
> > > -Daniel
> >
> > To sump up the conversation in the #dri-devel channel, these drivers
> > should support the following formats:
> >
> > 1) Dx (Daniel suggested that for darkness, but inverted mono)
>
> Did you consider format C1 instead?

That would be a 2-color display, which is not necessarily black
and white. Cfr. Amiga or Atari bit planes with bpp=1.
That's why fbdev has separate visuals for monochrome.

> I have no idea how this would map to fbdev API though.

    #define FB_VISUAL_MONO01                0       /* Monochr.
1=Black 0=White */
    #define FB_VISUAL_MONO10                1       /* Monochr.
1=White 0=Black */
    #define FB_VISUAL_TRUECOLOR             2       /* True color   */

The above is RGB (or grayscale, see below).

    #define FB_VISUAL_PSEUDOCOLOR           3       /* Pseudo color
(like atari) */

Palette

    #define FB_VISUAL_DIRECTCOLOR           4       /* Direct color */

Usually used as RGB with gamma correction, but the actual hardware
is more flexible.

    #define FB_VISUAL_STATIC_PSEUDOCOLOR    5       /* Pseudo color readonly */

Fixed palette

And:

    struct fb_var_screeninfo {
            ...
            __u32 grayscale;                /* 0 = color, 1 = grayscale,    */

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Tue, 1 Feb 2022 12:07:07 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Pekka,
> 
> On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > On Tue, 1 Feb 2022 10:49:03 +0100
> > Javier Martinez Canillas <javierm@redhat.com> wrote:  
> > > On 2/1/22 09:38, Daniel Vetter wrote:  
> > > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:  
> > > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:  
> > > >>> What's the story with the Rn formats?
> > > >>>
> > > >>> The comments say "n bpp Red", while this is a monochrome (even
> > > >>> inverted) display?  
> > > >>
> > > >> I don't think the color matters that much. "Red" was picked just because it was
> > > >> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?  
> > > >
> > > > The red comes from gl, where with shaders it really doesn't matter
> > > > what meaning you attach to channels, but really just how many you
> > > > have. So 2-channel formats are called RxGx, 3-channel RxGxBx,
> > > > 4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for
> > > > interop in general, hence why these exist.
> > > >
> > > > We should probably make a comment that this really isn't a red channel
> > > > when used for display it's a greyscale/intensity format. Aside from
> > > > that documentation gap I think reusing Rx formats for
> > > > greyscale/intensity for display makes perfect sense.
> > > > -Daniel  
> > >
> > > To sump up the conversation in the #dri-devel channel, these drivers
> > > should support the following formats:
> > >
> > > 1) Dx (Daniel suggested that for darkness, but inverted mono)  
> >
> > Did you consider format C1 instead?  
> 
> That would be a 2-color display, which is not necessarily black
> and white. Cfr. Amiga or Atari bit planes with bpp=1.
> That's why fbdev has separate visuals for monochrome.

Yes, that is exactly what I was aiming at: to draft a plan for panels
that have a fixed and arbitrary palette. From the discussions I
understood that the panel in question here requires somehow reversed
colors ("inverted mono"), which didn't really sound to be like "normal
monochrome".

> > I have no idea how this would map to fbdev API though.  
> 
>     #define FB_VISUAL_MONO01                0       /* Monochr.
> 1=Black 0=White */
>     #define FB_VISUAL_MONO10                1       /* Monochr.
> 1=White 0=Black */
>     #define FB_VISUAL_TRUECOLOR             2       /* True color   */
> 
> The above is RGB (or grayscale, see below).
> 
>     #define FB_VISUAL_PSEUDOCOLOR           3       /* Pseudo color
> (like atari) */
> 
> Palette
> 
>     #define FB_VISUAL_DIRECTCOLOR           4       /* Direct color */
> 
> Usually used as RGB with gamma correction, but the actual hardware
> is more flexible.
> 
>     #define FB_VISUAL_STATIC_PSEUDOCOLOR    5       /* Pseudo color readonly */
> 
> Fixed palette
> 
> And:
> 
>     struct fb_var_screeninfo {
>             ...
>             __u32 grayscale;                /* 0 = color, 1 = grayscale,    */

DRM has pixel formats, but no visuals so far. Maybe it needs to grow
the concept of visuals in some form? However, care should be taken to
not clash with existing colorimetry features. I would hope that the
colorimetry feature set could be extended to cover the above as well.
Well, only if there would be any users for it.

My silly attempt with Cx formats (e.g. DRM_FORMAT_C8) was a stab in that
direction, but maybe not flexible enough for the above.

If on the other hand the panel is "grayscale" but with an arbitrary
color (white, green, orange or other on black), the IRC consensus seems
to be that one should use Rx formats (e.g. DRM_FORMAT_R8) for it,
regardless of the actual color. That would convey that the pixel value
has a monotonic (increasing) mapping to brightness, unlike with
paletted formats. I agree with this, but wonder how reversed brightness
should be dealt with - or just have the driver invert the pixel values
before sending them to display?

Cx formats with a read-only palette could be used to represent
"grayscale" and "reversed grayscale" too, but people seem to think that
is too complicated to analyse and use for KMS userspace.

Other #dri-devel IRC mumblings were about maybe adding a DRM pixel
format for grayscale or intensity or luminance so that one would not
need to use "red" color channel for something that doesn't look red.
That is, do not use Cx formats because those produce completely
arbitrary colors, and do not use Rx formats because the display is not
redscale. Personally I'd be fine with Rx formats.


Thanks,
pq

Hi Pekka,

On Wed, Feb 2, 2022 at 10:20 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Tue, 1 Feb 2022 12:07:07 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > On Tue, 1 Feb 2022 10:49:03 +0100
> > > Javier Martinez Canillas <javierm@redhat.com> wrote:
> > > > On 2/1/22 09:38, Daniel Vetter wrote:
> > > > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:
> > > > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > >>> What's the story with the Rn formats?
> > > > >>>
> > > > >>> The comments say "n bpp Red", while this is a monochrome (even
> > > > >>> inverted) display?
> > > > >>
> > > > >> I don't think the color matters that much. "Red" was picked just because it was
> > > > >> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?
> > > > >
> > > > > The red comes from gl, where with shaders it really doesn't matter
> > > > > what meaning you attach to channels, but really just how many you
> > > > > have. So 2-channel formats are called RxGx, 3-channel RxGxBx,
> > > > > 4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for
> > > > > interop in general, hence why these exist.
> > > > >
> > > > > We should probably make a comment that this really isn't a red channel
> > > > > when used for display it's a greyscale/intensity format. Aside from
> > > > > that documentation gap I think reusing Rx formats for
> > > > > greyscale/intensity for display makes perfect sense.
> > > > > -Daniel
> > > >
> > > > To sump up the conversation in the #dri-devel channel, these drivers
> > > > should support the following formats:
> > > >
> > > > 1) Dx (Daniel suggested that for darkness, but inverted mono)
> > >
> > > Did you consider format C1 instead?
> >
> > That would be a 2-color display, which is not necessarily black
> > and white. Cfr. Amiga or Atari bit planes with bpp=1.
> > That's why fbdev has separate visuals for monochrome.
>
> Yes, that is exactly what I was aiming at: to draft a plan for panels
> that have a fixed and arbitrary palette. From the discussions I
> understood that the panel in question here requires somehow reversed
> colors ("inverted mono"), which didn't really sound to be like "normal
> monochrome".
>
> > > I have no idea how this would map to fbdev API though.
> >
> >     #define FB_VISUAL_MONO01                0       /* Monochr.
> > 1=Black 0=White */
> >     #define FB_VISUAL_MONO10                1       /* Monochr.
> > 1=White 0=Black */
> >     #define FB_VISUAL_TRUECOLOR             2       /* True color   */
> >
> > The above is RGB (or grayscale, see below).
> >
> >     #define FB_VISUAL_PSEUDOCOLOR           3       /* Pseudo color
> > (like atari) */
> >
> > Palette
> >
> >     #define FB_VISUAL_DIRECTCOLOR           4       /* Direct color */
> >
> > Usually used as RGB with gamma correction, but the actual hardware
> > is more flexible.
> >
> >     #define FB_VISUAL_STATIC_PSEUDOCOLOR    5       /* Pseudo color readonly */
> >
> > Fixed palette
> >
> > And:
> >
> >     struct fb_var_screeninfo {
> >             ...
> >             __u32 grayscale;                /* 0 = color, 1 = grayscale,    */
>
> DRM has pixel formats, but no visuals so far. Maybe it needs to grow
> the concept of visuals in some form? However, care should be taken to
> not clash with existing colorimetry features. I would hope that the
> colorimetry feature set could be extended to cover the above as well.
> Well, only if there would be any users for it.

Fbdev has separate (orthogonal) settings for
  1. Frame buffer layout (FB_TYPE_*),
  2. Pixel format (depth and fb_bitfields),
  3. Visual.
DRM combines all of the above in a fourcc value.

Nowadays most frame buffer layouts are packed, so using a shadow
frame buffer to support other layouts is very helpful, as it means
applications no longer have to care about legacy frame buffer layouts.

> My silly attempt with Cx formats (e.g. DRM_FORMAT_C8) was a stab in that
> direction, but maybe not flexible enough for the above.
>
> If on the other hand the panel is "grayscale" but with an arbitrary
> color (white, green, orange or other on black), the IRC consensus seems
> to be that one should use Rx formats (e.g. DRM_FORMAT_R8) for it,
> regardless of the actual color. That would convey that the pixel value
> has a monotonic (increasing) mapping to brightness, unlike with
> paletted formats. I agree with this, but wonder how reversed brightness

Agreed, the only thing that matters is a monotonic mapping, and
whether it's increasing or decreasing.

> should be dealt with - or just have the driver invert the pixel values
> before sending them to display?

That's an option. If the data has to be copied anyway, inversion is
a cheap operation. Else I think you need new fourcc types.

> Cx formats with a read-only palette could be used to represent
> "grayscale" and "reversed grayscale" too, but people seem to think that
> is too complicated to analyse and use for KMS userspace.

Yeah, it's complicated, but rather rare. Most desktop hardware
(even from the nineties ;-) does support a programmable palette.
Exceptions are CGA, the C64 (no Linux support yet ;-), and eInk
displays that support e.g. white, black, and red.

If you do want to support it, perhaps introduce Fx (F = fixed)
fourcc types?

> Other #dri-devel IRC mumblings were about maybe adding a DRM pixel
> format for grayscale or intensity or luminance so that one would not
> need to use "red" color channel for something that doesn't look red.
> That is, do not use Cx formats because those produce completely
> arbitrary colors, and do not use Rx formats because the display is not
> redscale. Personally I'd be fine with Rx formats.

Fine, as said above, monotonic mapping is what matters.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Hi Javier,

On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.

Thanks for your series!

I'll give it a try on an Adafruit FeatherWing 128x32 OLED, connected
to an OrangeCrab ECP5 FPGA board running a 64 MHz VexRiscv RISC-V
softcore.

> Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest
> (https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes:
>
>      ./fbtest -f /dev/fb1
>     Using drawops cfb32 (32 bpp packed pixels)
>     Available visuals:
>       Monochrome
>       Grayscale 256
>       Truecolor 8:8:8:0

Oh, fake 32-bpp truecolor ;-)

Does it run modetest, too?

I'm trying to get modetest working on my atari DRM driver.
Comparing to the cirrus driver doesn't help much, as modetest doesn't
seem to work with the cirrus driver (modified to not do hardware
access, as I don't have cirrus hardware):

    # modetest -M cirrus -s 31:1024x768-60Hz
    setting mode 1024x768-60.00Hz on connectors 31, crtc 34
    failed to set gamma: Function not implemented

Does there exist another simple test program for showing something
using the DRM API?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Tuesday, February 1st, 2022 at 09:43, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Does there exist another simple test program for showing something
> using the DRM API?

If you're fine with going low-level, there's tentative [1] which can apply an
arbitrary KMS state. See for instance [2] for basic mode-setting.

[1]: https://git.sr.ht/~emersion/tentative
[2]: https://git.sr.ht/~emersion/tentative/tree/master/item/examples/modeset

Hello Geert,

On 2/1/22 09:43, Geert Uytterhoeven wrote:
> Hi Javier,
> 
> On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
>> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
> 
> Thanks for your series!
> 
> I'll give it a try on an Adafruit FeatherWing 128x32 OLED, connected
> to an OrangeCrab ECP5 FPGA board running a 64 MHz VexRiscv RISC-V
> softcore.
>

Awesome! let me know if you have any issues. I keep an update-to-date version
at https://github.com/martinezjavier/linux/tree/ssd1307

>> Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest
>> (https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes:
>>
>>      ./fbtest -f /dev/fb1
>>     Using drawops cfb32 (32 bpp packed pixels)
>>     Available visuals:
>>       Monochrome
>>       Grayscale 256
>>       Truecolor 8:8:8:0
> 
> Oh, fake 32-bpp truecolor ;-)
>

Yes :) that's what the repaper drivers does to have maximum compatibility
with existing user-space and I followed the same.
 
> Does it run modetest, too?
>

It does, yes. And for example `modetest -M ssd1307` will print all the
info about encoders, connectors, CRTs, etc.
 
> I'm trying to get modetest working on my atari DRM driver.
> Comparing to the cirrus driver doesn't help much, as modetest doesn't
> seem to work with the cirrus driver (modified to not do hardware
> access, as I don't have cirrus hardware):
> 
>     # modetest -M cirrus -s 31:1024x768-60Hz
>     setting mode 1024x768-60.00Hz on connectors 31, crtc 34
>     failed to set gamma: Function not implemented
>

# modetest -M ssd1307 -c -s 31:128x64-0.12Hz
...
setting mode 128x64-0.12Hz on connectors 31, crtc 33
failed to set gamma: Function not implemented

this seems to be a bug in modetest. I found a patch posted some time ago
but never landed: https://www.spinics.net/lists/dri-devel/msg251356.html
 
> Does there exist another simple test program for showing something
> using the DRM API?
>

I tested with plymouth and gdm that make use of the DRM API, they do
start and I see something on the screen but don't really handle that
well the fact that's a 128x64 resolution.

I didn't test with more DRM programs because was mostly interested in
making sure that the fbdev emulation was working correctly.

Noticed that Simon shared some simple examples, I'll give them a try. 

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat