| Message ID | 20220131201225.2324984-1-javierm@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/tiny: Add driver for Solomon SSD1307 OLED displays | expand |
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,
On 1/31/22 21:56, Sam Ravnborg wrote: > Hi Javier, > On Mon, Jan 31, 2022 at 09:12:20PM +0100, Javier Martinez Canillas 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. >> >> 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: > > Impressed how fast you did this! > Saw the picture you posted a link to on irc - nice. > Thanks :) What's impressive is how many helper functions the DRM core has, so typing a new DRM driver is something that could be achieved in a few hours. Which was one of my goals with this experiment, to understand how much effort would be for a developer with no prior experience with DRM to port a fbdev driver. >> 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. > Looking forward the name ssd130x would make more sense. There is only so > many existing users and a potential of much more new users. > So in my color of the world the naming that benefits the most users > wins. > Agreed. That's also what Andy suggested and makes a lot of sense to me. > Sam > Best regards,
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
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
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
On Mon, Jan 31, 2022 at 09:56:23PM +0100, Sam Ravnborg wrote: > On Mon, Jan 31, 2022 at 09:12:20PM +0100, Javier Martinez Canillas wrote: ... > > 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. > Looking forward the name ssd130x would make more sense. There is only so > many existing users and a potential of much more new users. > So in my color of the world the naming that benefits the most users > wins. It depends if the binding is going to be preserved. Also this series doesn't answer to the question what to do with the old driver. If you leave it, I would expect the backward compatibility, otherwise the series misses removal of the old driver.
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,
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
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
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,
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 2/1/22 10:37, Andy Shevchenko wrote: > On Mon, Jan 31, 2022 at 09:56:23PM +0100, Sam Ravnborg wrote: >> On Mon, Jan 31, 2022 at 09:12:20PM +0100, Javier Martinez Canillas wrote: > > ... > >>> 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. >> Looking forward the name ssd130x would make more sense. There is only so >> many existing users and a potential of much more new users. >> So in my color of the world the naming that benefits the most users >> wins. > > It depends if the binding is going to be preserved. Also this series doesn't > answer to the question what to do with the old driver. > I don't plan to remove the old driver (yet). My goal here is to have an answer for Fedora users that might complain that we disabled all the fbdev drivers. So I wanted to understand the effort involved in porting a fbdev driver to DRM. > If you leave it, I would expect the backward compatibility, otherwise the > series misses removal of the old driver. > I don't see how those two are correlated. You just need different compatible strings to match the new and old drivers. That what was usually done for DRM drivers that were ported. To give an example, the "omapfb" vs "omapdrm". Since the current binding has a compatible "ssd1305fb-i2c", we could make the new one "ssd1305drm-i2c" or better, just "ssd1305-i2c". Best regards,
Hi Javier, On Tue, Feb 1, 2022 at 12:31 PM Javier Martinez Canillas <javierm@redhat.com> wrote: > On 2/1/22 10:37, Andy Shevchenko wrote: > > On Mon, Jan 31, 2022 at 09:56:23PM +0100, Sam Ravnborg wrote: > >> On Mon, Jan 31, 2022 at 09:12:20PM +0100, Javier Martinez Canillas wrote: > > > > ... > > > >>> 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. > >> Looking forward the name ssd130x would make more sense. There is only so > >> many existing users and a potential of much more new users. > >> So in my color of the world the naming that benefits the most users > >> wins. > > > > It depends if the binding is going to be preserved. Also this series doesn't > > answer to the question what to do with the old driver. > > > > I don't plan to remove the old driver (yet). My goal here is to have an answer > for Fedora users that might complain that we disabled all the fbdev drivers. > > So I wanted to understand the effort involved in porting a fbdev driver to DRM. > > > If you leave it, I would expect the backward compatibility, otherwise the > > series misses removal of the old driver. > > > > I don't see how those two are correlated. You just need different compatible > strings to match the new and old drivers. That what was usually done for DRM > drivers that were ported. To give an example, the "omapfb" vs "omapdrm". > > Since the current binding has a compatible "ssd1305fb-i2c", we could make the > new one "ssd1305drm-i2c" or better, just "ssd1305-i2c". DT describes hardware, not software policy. If the hardware is the same, the DT bindings should stay the same. 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
Hello Geert, On 2/1/22 12:38, Geert Uytterhoeven wrote: [snip] >> >> Since the current binding has a compatible "ssd1305fb-i2c", we could make the >> new one "ssd1305drm-i2c" or better, just "ssd1305-i2c". > > DT describes hardware, not software policy. > If the hardware is the same, the DT bindings should stay the same. > Yes I know that but the thing is that the current binding don't describe the hardware correctly. For instance, don't use a backlight DT node as a property of the panel and have this "fb" suffix in the compatible strings. Having said that, my opinion is that we should just keep with the existing bindings and make compatible to that even if isn't completely correct. Since that will ease adoption of the new DRM driver and allow users to use it without the need to update their DTBs. Best regards,
Hi Javier, On Tue, Feb 1, 2022 at 2:09 PM Javier Martinez Canillas <javierm@redhat.com> wrote: > On 2/1/22 12:38, Geert Uytterhoeven wrote: > >> Since the current binding has a compatible "ssd1305fb-i2c", we could make the > >> new one "ssd1305drm-i2c" or better, just "ssd1305-i2c". > > > > DT describes hardware, not software policy. > > If the hardware is the same, the DT bindings should stay the same. > > > > Yes I know that but the thing is that the current binding don't describe > the hardware correctly. For instance, don't use a backlight DT node as a > property of the panel and have this "fb" suffix in the compatible strings. > > Having said that, my opinion is that we should just keep with the existing > bindings and make compatible to that even if isn't completely correct. > > Since that will ease adoption of the new DRM driver and allow users to use > it without the need to update their DTBs. To me it looks like the pwms property is not related to the backlight at all, and only needed for some variants? And the actual backlight code seems to be about internal contrast adjustment? So if the pwms usage is OK, what other reasons are there to break DT compatibility? IMHO just the "fb" suffix is not a good reason. 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
Hello Geert, On 2/1/22 15:14, Geert Uytterhoeven wrote: > Hi Javier, > > On Tue, Feb 1, 2022 at 2:09 PM Javier Martinez Canillas > <javierm@redhat.com> wrote: >> On 2/1/22 12:38, Geert Uytterhoeven wrote: >>>> Since the current binding has a compatible "ssd1305fb-i2c", we could make the >>>> new one "ssd1305drm-i2c" or better, just "ssd1305-i2c". >>> >>> DT describes hardware, not software policy. >>> If the hardware is the same, the DT bindings should stay the same. >>> >> >> Yes I know that but the thing is that the current binding don't describe >> the hardware correctly. For instance, don't use a backlight DT node as a >> property of the panel and have this "fb" suffix in the compatible strings. >> >> Having said that, my opinion is that we should just keep with the existing >> bindings and make compatible to that even if isn't completely correct. >> >> Since that will ease adoption of the new DRM driver and allow users to use >> it without the need to update their DTBs. > > To me it looks like the pwms property is not related to the backlight > at all, and only needed for some variants? > I was reading the datasheets of the ssd1305, ssd1306 and ssd1307. Only the first one mentions anything about a PWM and says: In phase 3, the OLED driver switches to use current source to drive the OLED pixels and this is the current drive stage. SSD1305 employs PWM (Pulse Width Modulation) method to control the brightness of area color A, B, C, D color individually. The longer the waveform in current drive stage is, the brighter is the pixel and vice versa. After finishing phase 3, the driver IC will go back to phase 1 to display the next row image data. This threestep cycle is run continuously to refresh image display on OLED panel. The way I understand this is that the PWM isn't used for the backlight but instead to power the IC and allow to display the actual pixels ? And this matches what Maxime mentioned in this patch: https://linux-arm-kernel.infradead.narkive.com/5i44FnQ8/patch-1-2-video-ssd1307fb-add-support-for-ssd1306-oled-controller The Solomon SSD1306 OLED controller is very similar to the SSD1307, except for the fact that the power is given through an external PWM for the 1307, and while the 1306 can generate its own power without any PWM. > And the actual backlight code seems to be about internal contrast > adjustment? > > So if the pwms usage is OK, what other reasons are there to break > DT compatibility? IMHO just the "fb" suffix is not a good reason. > Absolutely agreed with you on this. It seems we should just use the existing binding and make the driver compatible with that. The only value is that the drm_panel infrastructure could be used, but making it backward compatible is more worthy IMO. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Hi Javier, On Tue, Feb 01, 2022 at 04:03:30PM +0100, Javier Martinez Canillas wrote: > Hello Geert, > > On 2/1/22 15:14, Geert Uytterhoeven wrote: > > Hi Javier, > > > > On Tue, Feb 1, 2022 at 2:09 PM Javier Martinez Canillas > > <javierm@redhat.com> wrote: > >> On 2/1/22 12:38, Geert Uytterhoeven wrote: > >>>> Since the current binding has a compatible "ssd1305fb-i2c", we could make the > >>>> new one "ssd1305drm-i2c" or better, just "ssd1305-i2c". > >>> > >>> DT describes hardware, not software policy. > >>> If the hardware is the same, the DT bindings should stay the same. Only if the bindings describe the HW in a correct way that is. > >>> > >> > >> Yes I know that but the thing is that the current binding don't describe > >> the hardware correctly. For instance, don't use a backlight DT node as a > >> property of the panel and have this "fb" suffix in the compatible strings. > >> > >> Having said that, my opinion is that we should just keep with the existing > >> bindings and make compatible to that even if isn't completely correct. > >> > >> Since that will ease adoption of the new DRM driver and allow users to use > >> it without the need to update their DTBs. > > > > To me it looks like the pwms property is not related to the backlight > > at all, and only needed for some variants? > > > > I was reading the datasheets of the ssd1305, ssd1306 and ssd1307. Only the > first one mentions anything about a PWM and says: > > In phase 3, the OLED driver switches to use current source to drive the > OLED pixels and this is the current drive stage. SSD1305 employs PWM > (Pulse Width Modulation) method to control the brightness of area color > A, B, C, D color individually. The longer the waveform in current drive > stage is, the brighter is the pixel and vice versa. > > After finishing phase 3, the driver IC will go back to phase 1 to display > the next row image data. This threestep cycle is run continuously to refresh > image display on OLED panel. > > The way I understand this is that the PWM isn't used for the backlight > but instead to power the IC and allow to display the actual pixels ? > > And this matches what Maxime mentioned in this patch: > > https://linux-arm-kernel.infradead.narkive.com/5i44FnQ8/patch-1-2-video-ssd1307fb-add-support-for-ssd1306-oled-controller > > The Solomon SSD1306 OLED controller is very similar to the SSD1307, > except for the fact that the power is given through an external PWM for > the 1307, and while the 1306 can generate its own power without any PWM. I took a look at the datasheets - and all ssd1305, ssd1306 and ssd1307 are the same. They have timing constrains on the Vcc. The random schematic I found on the net showed me that a PWM was used to control the Vcc voltage - which again is used to control the brightness. All the above has nothing to do with backlight - I had this mixed up in my head. So my current understanding: - solomon,ssd1307fb.yaml should NOT include a backlight node - because the backlight is something included in the ssd130x device and not something separate. - 1305, 1306, and 1307 (I did not check 1309) all requires a Vcc supply that shall be turned on/off according to the datasheet. This implies that we need a regulaator for Vcc - and the regulator could be a pwm based regulator or something else - the HW do not care. - But I can see that several design connect Vcc to a fixed voltage, so I am not too sure about this part. I think the correct binding would have ssd1307 => regulator => pwm So the ssd1307 binding references a regulator, and the regulator may use an pwm or may use something else. The current binding references a vbat supply - but the datasheet do not mention any vbat. It is most likely modelling the Vdd supply. Right now my take is to go the simple route: - Keep the binding as is and just use the pwm as already implemented - Likewise keep the backlight as is Last I recommend to drop the fbdev variant - if the drm driver has any regressions we can fix them. And I do not see any other way to move users over. Unless their setup breaks then they do not change. > > > And the actual backlight code seems to be about internal contrast > > adjustment? > > > > So if the pwms usage is OK, what other reasons are there to break > > DT compatibility? IMHO just the "fb" suffix is not a good reason. > > > > Absolutely agreed with you on this. It seems we should just use the existing > binding and make the driver compatible with that. The only value is that the > drm_panel infrastructure could be used, but making it backward compatible is > more worthy IMO. Using drm_panel here would IMO just complicate things - it is not that we will see many different panels (I think). Sam
Hello Sam, On 2/1/22 21:40, Sam Ravnborg wrote: [snip] > > I took a look at the datasheets - and all ssd1305, ssd1306 and ssd1307 > are the same. They have timing constrains on the Vcc. > The random schematic I found on the net showed me that a PWM was used to > control the Vcc voltage - which again is used to control the brightness. > > All the above has nothing to do with backlight - I had this mixed up in > my head. > Yes, same here. I was leaning towards fixing the DT binding but then due Geert comment and after reading the datasheets for ssd130{5,6,7} like you I had the same understanding. Glad that you agree. [snip] > > Last I recommend to drop the fbdev variant - if the drm driver has any > regressions we can fix them. And I do not see any other way to move > users over. Unless their setup breaks then they do not change. > As I mentioned in this thread I wouldn't propose to drop the fbdev variant. I prefer to use the carrot and not the stick. Peter Robinson suggested to make the driver mutually exclusive and add !FB_SSD1307 in the config symbol. I think that makes sense and will do it in v2. Best regards,
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
On Wed, Feb 02, 2022 at 09:38:51AM +0100, Javier Martinez Canillas wrote: > On 2/1/22 21:40, Sam Ravnborg wrote: ... > Peter Robinson suggested to > make the driver mutually exclusive and add !FB_SSD1307 in the config symbol. And how will distros choose "the right" option in this case? What to do when I wan to see a regression and I want to change drivers w/o recompilation? NAK from me to that proposal.
Hello Andy, On 2/2/22 12:06, Andy Shevchenko wrote: > On Wed, Feb 02, 2022 at 09:38:51AM +0100, Javier Martinez Canillas wrote: >> On 2/1/22 21:40, Sam Ravnborg wrote: > > ... > >> Peter Robinson suggested to >> make the driver mutually exclusive and add !FB_SSD1307 in the config symbol. > > And how will distros choose "the right" option in this case? It depends on the distro. In Fedora we are disabling *all* the fbdev drivers. > What to do when I wan to see a regression and I want to change drivers w/o > recompilation? > If you want to have the two drivers without recompilation (and same compatible to match) then how would kmod / udev choose which one to load ? It becomes a race condition between the two drivers which one probes first. > NAK from me to that proposal. > What's your suggestion then to solve the issue mentioned above ? With my distro maintainer hat I don't care that much, since the fbdev drivers will be disabled. Best regards,
On Wed, Feb 02, 2022 at 12:39:29PM +0100, Javier Martinez Canillas wrote: > On 2/2/22 12:06, Andy Shevchenko wrote: > > On Wed, Feb 02, 2022 at 09:38:51AM +0100, Javier Martinez Canillas wrote: > >> On 2/1/22 21:40, Sam Ravnborg wrote: > > And how will distros choose "the right" option in this case? > > It depends on the distro. In Fedora we are disabling *all* the fbdev drivers. Yes, and Distro A will think about old driver (because they have customers and don't want to have a bad user experience) and Distro F will choose a new one. > > What to do when I wan to see a regression and I want to change drivers w/o > > recompilation? > > If you want to have the two drivers without recompilation (and same compatible > to match) then how would kmod / udev choose which one to load ? It becomes a > race condition between the two drivers which one probes first. We have a long history in kernel where new drivers came and old faded. When two or more drivers of the same feature is enabled in the kernel we may use modprobe facilities to prioritize them (blacklisting). > > NAK from me to that proposal. > > What's your suggestion then to solve the issue mentioned above ? With my distro > maintainer hat I don't care that much, since the fbdev drivers will be disabled. I think both of them can work together. If user doesn't care, the first one wins.
On 2/2/22 12:50, Andy Shevchenko wrote: [snip] >> What's your suggestion then to solve the issue mentioned above ? With my distro >> maintainer hat I don't care that much, since the fbdev drivers will be disabled. > > I think both of them can work together. If user doesn't care, the first one wins. > I don't think this is a good idea but as mentioned I don't really care that much since we will disable all fbdev drivers anyway. So I'm happy to allow them both. Best regards,
On Wed, Feb 02, 2022 at 12:54:32PM +0100, Javier Martinez Canillas wrote: > On 2/2/22 12:50, Andy Shevchenko wrote: > >> What's your suggestion then to solve the issue mentioned above ? With my distro > >> maintainer hat I don't care that much, since the fbdev drivers will be disabled. > > > > I think both of them can work together. If user doesn't care, the first one wins. > > I don't think this is a good idea but as mentioned I don't really care that much > since we will disable all fbdev drivers anyway. So I'm happy to allow them both. Thanks!
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