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
Add support to convert 8-bit grayscale to reversed monochrome for drivers
that control monochromatic displays, that only have 1 bit per pixel depth.
This helper function was based on repaper_gray8_to_mono_reversed() from
the drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
drivers/gpu/drm/drm_format_helper.c | 35 +++++++++++++++++++++++++++++
include/drm/drm_format_helper.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c b/drivers/gpu/drm/drm_format_helper.c
index 0f28dd2bdd72..bf477c136082 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
return -EINVAL;
}
EXPORT_SYMBOL(drm_fb_blit_toio);
+
+/**
+ * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
+ * @dst: reversed monochrome destination buffer
+ * @src: 8-bit grayscale source buffer
+ * @clip: Clip rectangle area to copy
+ *
+ * DRM doesn't have native monochrome or grayscale support.
+ * Such drivers can announce the commonly supported XR24 format to userspace
+ * and use drm_fb_xrgb8888_to_gray8() to convert to grayscale and then this
+ * helper function to convert to the native format.
+ */
+void drm_fb_gray8_to_mono_reversed(void *dst, void *src, const struct drm_rect *clip)
+{
+ size_t width = drm_rect_width(clip);
+ size_t height = drm_rect_width(clip);
+
+ u8 *mono = dst, *gray8 = src;
+ unsigned int y, xb, i;
+
+ for (y = 0; y < height; y++)
+ for (xb = 0; xb < width / 8; xb++) {
+ u8 byte = 0x00;
+
+ for (i = 0; i < 8; i++) {
+ int x = xb * 8 + i;
+
+ byte >>= 1;
+ if (gray8[y * width + x] >> 7)
+ byte |= BIT(7);
+ }
+ *mono++ = byte;
+ }
+}
+EXPORT_SYMBOL(drm_fb_gray8_to_mono_reversed);
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index b30ed5de0a33..cd4c8b7c78de 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -43,4 +43,6 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
const void *vmap, const struct drm_framebuffer *fb,
const struct drm_rect *rect);
+void drm_fb_gray8_to_mono_reversed(void *dst, void *vaddr, const struct drm_rect *clip);
+
#endif /* __LINUX_DRM_FORMAT_HELPER_H */
--
2.34.1
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
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.
Hi Javier,
On Tue, Feb 1, 2022 at 12:31 PM Javier Martinez Canillas
<[email protected]> 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 -- [email protected]
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 <[email protected]> wrote:
>
> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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
Hi Simon,
On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <[email protected]> wrote:
> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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 -- [email protected]
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 10:59:43 +0100
Thomas Zimmermann <[email protected]> wrote:
> Hi
>
> Am 31.01.22 um 21:12 schrieb Javier Martinez Canillas:
> > Add support to convert 8-bit grayscale to reversed monochrome for drivers
> > that control monochromatic displays, that only have 1 bit per pixel depth.
> >
> > This helper function was based on repaper_gray8_to_mono_reversed() from
> > the drivers/gpu/drm/tiny/repaper.c driver.
>
> You could convert repaper to the new helper.
>
> >
> > Signed-off-by: Javier Martinez Canillas <[email protected]>
> > ---
> >
> > drivers/gpu/drm/drm_format_helper.c | 35 +++++++++++++++++++++++++++++
> > include/drm/drm_format_helper.h | 2 ++
> > 2 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_format_helper.c b/drivers/gpu/drm/drm_format_helper.c
> > index 0f28dd2bdd72..bf477c136082 100644
> > --- a/drivers/gpu/drm/drm_format_helper.c
> > +++ b/drivers/gpu/drm/drm_format_helper.c
> > @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
> > return -EINVAL;
> > }
> > EXPORT_SYMBOL(drm_fb_blit_toio);
> > +
> > +/**
> > + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
> > + * @dst: reversed monochrome destination buffer
> > + * @src: 8-bit grayscale source buffer
> > + * @clip: Clip rectangle area to copy
> > + *
> > + * DRM doesn't have native monochrome or grayscale support.
> > + * Such drivers can announce the commonly supported XR24 format to userspace
> > + * and use drm_fb_xrgb8888_to_gray8() to convert to grayscale and then this
> > + * helper function to convert to the native format.
> > + */
> > +void drm_fb_gray8_to_mono_reversed(void *dst, void *src, const struct drm_rect *clip)
>
> IMHO it would be better to have a function that converts xrgb8888 to
> mono and let it handle the intermediate step of gray8.
>
> > +{
> > + size_t width = drm_rect_width(clip);
> > + size_t height = drm_rect_width(clip);
> > +
> > + u8 *mono = dst, *gray8 = src;
> > + unsigned int y, xb, i;
> > +
> > + for (y = 0; y < height; y++)
> > + for (xb = 0; xb < width / 8; xb++) {
>
> The inner loop should probably go into a separate helper function. See
> the drm_fb_*_line() helpers in this file
>
> At some point, we's want to have a single blit helper that takes source
> and destination formats/buffers. It would then pick the correct per-line
> helper for the conversion. So yeah, we'd want something composable.
Btw. VKMS is going to do blending, and it needs to support various
formats, so the latest patches from Igor probably do something similar.
Thanks,
pq
>
> Best regards
> Thomas
>
> > + u8 byte = 0x00;
> > +
> > + for (i = 0; i < 8; i++) {
> > + int x = xb * 8 + i;
> > +
> > + byte >>= 1;
> > + if (gray8[y * width + x] >> 7)
> > + byte |= BIT(7);
> > + }
> > + *mono++ = byte;
> > + }
> > +}
> > +EXPORT_SYMBOL(drm_fb_gray8_to_mono_reversed);
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
> <[email protected]> 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
On Tue, 1 Feb 2022 10:49:03 +0100
Javier Martinez Canillas <[email protected]> wrote:
> On 2/1/22 09:38, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <[email protected]> wrote:
> >>
> >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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
Am 01.02.22 um 11:11 schrieb Simon Ser:
> On Tuesday, February 1st, 2022 at 11:08, Thomas Zimmermann <[email protected]> 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 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.
--
With Best Regards,
Andy Shevchenko
Hi
Am 01.02.22 um 09:36 schrieb Geert Uytterhoeven:
> Hi Simon,
>
> On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <[email protected]> wrote:
>> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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 -- [email protected]
>
> 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 <[email protected]> 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.
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hi Pekka,
On Wed, Feb 2, 2022 at 10:20 AM Pekka Paalanen <[email protected]> wrote:
> On Tue, 1 Feb 2022 12:07:07 +0100
> Geert Uytterhoeven <[email protected]> wrote:
> > On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <[email protected]> wrote:
> > > On Tue, 1 Feb 2022 10:49:03 +0100
> > > Javier Martinez Canillas <[email protected]> wrote:
> > > > On 2/1/22 09:38, Daniel Vetter wrote:
> > > > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <[email protected]> wrote:
> > > > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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 -- [email protected]
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
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!
--
With Best Regards,
Andy Shevchenko
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
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.
--
With Best Regards,
Andy Shevchenko
On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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?
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.
--
With Best Regards,
Andy Shevchenko
Hi Javier,
On Tue, Feb 1, 2022 at 2:09 PM Javier Martinez Canillas
<[email protected]> 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 -- [email protected]
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/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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
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,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hi Javier,
On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
<[email protected]> 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 -- [email protected]
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 Pekka,
On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <[email protected]> wrote:
> On Tue, 1 Feb 2022 10:49:03 +0100
> Javier Martinez Canillas <[email protected]> wrote:
> > On 2/1/22 09:38, Daniel Vetter wrote:
> > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <[email protected]> wrote:
> > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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 -- [email protected]
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 <[email protected]> wrote:
> Hi Pekka,
>
> On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <[email protected]> wrote:
> > On Tue, 1 Feb 2022 10:49:03 +0100
> > Javier Martinez Canillas <[email protected]> wrote:
> > > On 2/1/22 09:38, Daniel Vetter wrote:
> > > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <[email protected]> wrote:
> > > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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
On 2/1/22 09:38, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <[email protected]> wrote:
>>
>> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <[email protected]> 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 Tuesday, February 1st, 2022 at 09:43, Geert Uytterhoeven <[email protected]> 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
Hi
Am 31.01.22 um 21:12 schrieb Javier Martinez Canillas:
> Add support to convert 8-bit grayscale to reversed monochrome for drivers
> that control monochromatic displays, that only have 1 bit per pixel depth.
>
> This helper function was based on repaper_gray8_to_mono_reversed() from
> the drivers/gpu/drm/tiny/repaper.c driver.
You could convert repaper to the new helper.
>
> Signed-off-by: Javier Martinez Canillas <[email protected]>
> ---
>
> drivers/gpu/drm/drm_format_helper.c | 35 +++++++++++++++++++++++++++++
> include/drm/drm_format_helper.h | 2 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c b/drivers/gpu/drm/drm_format_helper.c
> index 0f28dd2bdd72..bf477c136082 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
> return -EINVAL;
> }
> EXPORT_SYMBOL(drm_fb_blit_toio);
> +
> +/**
> + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
> + * @dst: reversed monochrome destination buffer
> + * @src: 8-bit grayscale source buffer
> + * @clip: Clip rectangle area to copy
> + *
> + * DRM doesn't have native monochrome or grayscale support.
> + * Such drivers can announce the commonly supported XR24 format to userspace
> + * and use drm_fb_xrgb8888_to_gray8() to convert to grayscale and then this
> + * helper function to convert to the native format.
> + */
> +void drm_fb_gray8_to_mono_reversed(void *dst, void *src, const struct drm_rect *clip)
IMHO it would be better to have a function that converts xrgb8888 to
mono and let it handle the intermediate step of gray8.
> +{
> + size_t width = drm_rect_width(clip);
> + size_t height = drm_rect_width(clip);
> +
> + u8 *mono = dst, *gray8 = src;
> + unsigned int y, xb, i;
> +
> + for (y = 0; y < height; y++)
> + for (xb = 0; xb < width / 8; xb++) {
The inner loop should probably go into a separate helper function. See
the drm_fb_*_line() helpers in this file
At some point, we's want to have a single blit helper that takes source
and destination formats/buffers. It would then pick the correct per-line
helper for the conversion. So yeah, we'd want something composable.
Best regards
Thomas
> + u8 byte = 0x00;
> +
> + for (i = 0; i < 8; i++) {
> + int x = xb * 8 + i;
> +
> + byte >>= 1;
> + if (gray8[y * width + x] >> 7)
> + byte |= BIT(7);
> + }
> + *mono++ = byte;
> + }
> +}
> +EXPORT_SYMBOL(drm_fb_gray8_to_mono_reversed);
> diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
> index b30ed5de0a33..cd4c8b7c78de 100644
> --- a/include/drm/drm_format_helper.h
> +++ b/include/drm/drm_format_helper.h
> @@ -43,4 +43,6 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
> const void *vmap, const struct drm_framebuffer *fb,
> const struct drm_rect *rect);
>
> +void drm_fb_gray8_to_mono_reversed(void *dst, void *vaddr, const struct drm_rect *clip);
> +
> #endif /* __LINUX_DRM_FORMAT_HELPER_H */
--
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
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
> <[email protected]> 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
Hello Thomas,
Thanks a lot for your feedback.
On 2/1/22 10:59, Thomas Zimmermann wrote:
> Hi
>
> Am 31.01.22 um 21:12 schrieb Javier Martinez Canillas:
>> Add support to convert 8-bit grayscale to reversed monochrome for drivers
>> that control monochromatic displays, that only have 1 bit per pixel depth.
>>
>> This helper function was based on repaper_gray8_to_mono_reversed() from
>> the drivers/gpu/drm/tiny/repaper.c driver.
>
> You could convert repaper to the new helper.
>
Yes, I plan to do it but was out of scope for this patch series.
>>
>> Signed-off-by: Javier Martinez Canillas <[email protected]>
>> ---
>>
>> drivers/gpu/drm/drm_format_helper.c | 35 +++++++++++++++++++++++++++++
>> include/drm/drm_format_helper.h | 2 ++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_format_helper.c b/drivers/gpu/drm/drm_format_helper.c
>> index 0f28dd2bdd72..bf477c136082 100644
>> --- a/drivers/gpu/drm/drm_format_helper.c
>> +++ b/drivers/gpu/drm/drm_format_helper.c
>> @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
>> return -EINVAL;
>> }
>> EXPORT_SYMBOL(drm_fb_blit_toio);
>> +
>> +/**
>> + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
>> + * @dst: reversed monochrome destination buffer
>> + * @src: 8-bit grayscale source buffer
>> + * @clip: Clip rectangle area to copy
>> + *
>> + * DRM doesn't have native monochrome or grayscale support.
>> + * Such drivers can announce the commonly supported XR24 format to userspace
>> + * and use drm_fb_xrgb8888_to_gray8() to convert to grayscale and then this
>> + * helper function to convert to the native format.
>> + */
>> +void drm_fb_gray8_to_mono_reversed(void *dst, void *src, const struct drm_rect *clip)
>
> IMHO it would be better to have a function that converts xrgb8888 to
> mono and let it handle the intermediate step of gray8.
>
That's a good idea. I'll add that too.
>> +{
>> + size_t width = drm_rect_width(clip);
>> + size_t height = drm_rect_width(clip);
>> +
>> + u8 *mono = dst, *gray8 = src;
>> + unsigned int y, xb, i;
>> +
>> + for (y = 0; y < height; y++)
>> + for (xb = 0; xb < width / 8; xb++) {
>
> The inner loop should probably go into a separate helper function. See
> the drm_fb_*_line() helpers in this file
>
> At some point, we's want to have a single blit helper that takes source
> and destination formats/buffers. It would then pick the correct per-line
> helper for the conversion. So yeah, we'd want something composable.
>
Agreed. I'll split that into a separate helper function.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Geert,
On 3/14/22 14:40, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
> <[email protected]> wrote:
>> Add support to convert 8-bit grayscale to reversed monochrome for drivers
>> that control monochromatic displays, that only have 1 bit per pixel depth.
>>
>> This helper function was based on repaper_gray8_to_mono_reversed() from
>> the drivers/gpu/drm/tiny/repaper.c driver.
>>
>> Signed-off-by: Javier Martinez Canillas <[email protected]>
>
>> --- a/drivers/gpu/drm/drm_format_helper.c
>> +++ b/drivers/gpu/drm/drm_format_helper.c
>> @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
>> return -EINVAL;
>> }
>> EXPORT_SYMBOL(drm_fb_blit_toio);
>> +
>> +/**
>> + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
>> + * @dst: reversed monochrome destination buffer
>
> What's the meaning of "reversed"?
Originally I took this helper from the repaper driver and it was called
repaper_gray8_to_mono_reversed(), so the naming just got carried over.
> During the last few days, I've been balancing between (a) "reverse
> video" and (b) "reverse bit order", but none of them seems to be true.
>
> (a) The code maps 0-127 to 0 and 8-255 to 1, which just reduces from
> 256 to 2 grayscale levels, without inversion. The result is also
> white-on-black on my ssd130x OLED.
> (b) On little-endian, the CFB drawops use little-endian bit order,
> which is what ends up in "byte" in the code below.
>
As far as I understand is (a) from the options since the repaper display
uses black-on-white. But as you pointed out the ssd130x OLEDs instead do
white-on-black.
I should had probably just name the helper drm_fb_gray8_to_monochrome()
or maybe drm_fb_gray8_to_gray1() ?
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hi Javier,
On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
<[email protected]> wrote:
> Add support to convert 8-bit grayscale to reversed monochrome for drivers
> that control monochromatic displays, that only have 1 bit per pixel depth.
>
> This helper function was based on repaper_gray8_to_mono_reversed() from
> the drivers/gpu/drm/tiny/repaper.c driver.
>
> Signed-off-by: Javier Martinez Canillas <[email protected]>
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t dst_for
> return -EINVAL;
> }
> EXPORT_SYMBOL(drm_fb_blit_toio);
> +
> +/**
> + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
> + * @dst: reversed monochrome destination buffer
What's the meaning of "reversed"?
During the last few days, I've been balancing between (a) "reverse
video" and (b) "reverse bit order", but none of them seems to be true.
(a) The code maps 0-127 to 0 and 8-255 to 1, which just reduces from
256 to 2 grayscale levels, without inversion. The result is also
white-on-black on my ssd130x OLED.
(b) On little-endian, the CFB drawops use little-endian bit order,
which is what ends up in "byte" in the code below.
> + * @src: 8-bit grayscale source buffer
> + * @clip: Clip rectangle area to copy
> + *
> + * DRM doesn't have native monochrome or grayscale support.
> + * Such drivers can announce the commonly supported XR24 format to userspace
> + * and use drm_fb_xrgb8888_to_gray8() to convert to grayscale and then this
> + * helper function to convert to the native format.
> + */
> +void drm_fb_gray8_to_mono_reversed(void *dst, void *src, const struct drm_rect *clip)
> +{
> + size_t width = drm_rect_width(clip);
> + size_t height = drm_rect_width(clip);
> +
> + u8 *mono = dst, *gray8 = src;
> + unsigned int y, xb, i;
> +
> + for (y = 0; y < height; y++)
> + for (xb = 0; xb < width / 8; xb++) {
> + u8 byte = 0x00;
> +
> + for (i = 0; i < 8; i++) {
> + int x = xb * 8 + i;
> +
> + byte >>= 1;
> + if (gray8[y * width + x] >> 7)
> + byte |= BIT(7);
> + }
> + *mono++ = byte;
> + }
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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