Question about sRGB framebuffer support

Question about sRGB framebuffer support

[Artem Mygaiev]

Hello all

I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
controller [1]. I have already implemented a POC driver [2] which is working for
me, although there are still plenty of things to improve or fix, of course.

So far I have one thing that I somehow cannot find in DRM/KMS documentation or
existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
color encoding in framebuffers? This is a HW limitation that I cannot influence
by configuration.

Any pointers are greatly appreciated.

[1] www.frescologic.com/product/single/fl2000
[2] https://github.com/klogg/fl2000_drm

Best regards,
 -- Artem
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Sam Ravnborg]

Hi Artem.

On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> Hello all
> 
> I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> controller [1]. I have already implemented a POC driver [2] which is working for
> me, although there are still plenty of things to improve or fix, of course.
> 
> So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> color encoding in framebuffers? This is a HW limitation that I cannot influence
> by configuration.
> 
> Any pointers are greatly appreciated.
No clue, I hope others can help you.

> 
> [1] www.frescologic.com/product/single/fl2000

> [2] https://github.com/klogg/fl2000_drm
I just visited your github site - and noticed you are using the
it66121 bridge.

Phong LE <ple@baylibre.com> have recently submitted a patch to
add this bridge to the kernel:
https://lore.kernel.org/dri-devel/20200311125135.30832-1-ple@baylibre.com/

I did not really looks at your code, awaits that you feel ready to submit
it.
	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Artem Mygaiev]

Hi Sam

On Tue, May 5, 2020 at 10:03 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Artem.
>
> On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > Hello all
> >
> > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > controller [1]. I have already implemented a POC driver [2] which is working for
> > me, although there are still plenty of things to improve or fix, of course.
> >
> > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > by configuration.
> >
> > Any pointers are greatly appreciated.
> No clue, I hope others can help you.
>

Meanwhile I have implemented conversion to rgb565 in driver, HW seem
to handle it correctly.

> >
> > [1] www.frescologic.com/product/single/fl2000
>
> > [2] https://github.com/klogg/fl2000_drm
> I just visited your github site - and noticed you are using the
> it66121 bridge.
>
> Phong LE <ple@baylibre.com> have recently submitted a patch to
> add this bridge to the kernel:
> https://lore.kernel.org/dri-devel/20200311125135.30832-1-ple@baylibre.com/

Thanks for the pointer, the code looks familiar :)

@Phong, feel free to add me to reviewers, I'll also test it with fl2k later on.

>
> I did not really looks at your code, awaits that you feel ready to submit
> it.
>         Sam

Best regards,
Artem Mygaiev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Ville Syrjälä]

On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> Hello all
> 
> I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> controller [1]. I have already implemented a POC driver [2] which is working for
> me, although there are still plenty of things to improve or fix, of course.
> 
> So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> color encoding in framebuffers? This is a HW limitation that I cannot influence
> by configuration.

Does it do something to process the data that requires linearization
or why does it care about the gamma applied to the data? In a typical
use case the data is just passed through unless the user asks otherwise,
so it doesn't matter much what gamma was used. Though most displays
probably expect something resembling sRGB gamma by default, so that's
presumably what most things generate, and images/videos/etc. pretty
much always have gamma already applied when they are produced.

> 
> Any pointers are greatly appreciated.
> 
> [1] www.frescologic.com/product/single/fl2000
> [2] https://github.com/klogg/fl2000_drm
> 
> Best regards,
>  -- Artem
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Artem Mygaiev]

Hello Ville

On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > Hello all
> >
> > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > controller [1]. I have already implemented a POC driver [2] which is working for
> > me, although there are still plenty of things to improve or fix, of course.
> >
> > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > by configuration.
>
> Does it do something to process the data that requires linearization
> or why does it care about the gamma applied to the data? In a typical
> use case the data is just passed through unless the user asks otherwise,
> so it doesn't matter much what gamma was used. Though most displays
> probably expect something resembling sRGB gamma by default, so that's
> presumably what most things generate, and images/videos/etc. pretty
> much always have gamma already applied when they are produced.
>

Unfortunately the HW was designed in a way that when it is configured to 24-bit
RGB888 it expects sRGB and applies degamma automatically. It is not possible to
disable this, I've asked vendor and they confirmed this [1].

The only workaround I could implement now is to switch it to 16-bit RGB565 and
perform framebuffer conversions in driver, similar to what
rm_fb_xrgb8888_to_rgb565() alike helpers do; but it would be still great to
understand whether it is possible to support sRGB.

[1] https://github.com/FrescoLogic/FL2000/issues/42

> >
> > Any pointers are greatly appreciated.
> >
> > [1] www.frescologic.com/product/single/fl2000
> > [2] https://github.com/klogg/fl2000_drm
> >
> > Best regards,
> >  -- Artem
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel

Best regards,
Artem Mygaiev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Ville Syrjälä]

On Wed, May 06, 2020 at 12:04:22PM +0300, Artem Mygaiev wrote:
> Hello Ville
> 
> On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > > Hello all
> > >
> > > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > > controller [1]. I have already implemented a POC driver [2] which is working for
> > > me, although there are still plenty of things to improve or fix, of course.
> > >
> > > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > > by configuration.
> >
> > Does it do something to process the data that requires linearization
> > or why does it care about the gamma applied to the data? In a typical
> > use case the data is just passed through unless the user asks otherwise,
> > so it doesn't matter much what gamma was used. Though most displays
> > probably expect something resembling sRGB gamma by default, so that's
> > presumably what most things generate, and images/videos/etc. pretty
> > much always have gamma already applied when they are produced.
> >
> 
> Unfortunately the HW was designed in a way that when it is configured to 24-bit
> RGB888 it expects sRGB and applies degamma automatically. It is not possible to
> disable this, I've asked vendor and they confirmed this [1].

So it always does degamma+gamma for no real reason? That shouldn't
really matter (apart from potentially losing some precision in those
conversions).

> 
> The only workaround I could implement now is to switch it to 16-bit RGB565 and
> perform framebuffer conversions in driver, similar to what
> rm_fb_xrgb8888_to_rgb565() alike helpers do; but it would be still great to
> understand whether it is possible to support sRGB.
> 
> [1] https://github.com/FrescoLogic/FL2000/issues/42
> 
> > >
> > > Any pointers are greatly appreciated.
> > >
> > > [1] www.frescologic.com/product/single/fl2000
> > > [2] https://github.com/klogg/fl2000_drm
> > >
> > > Best regards,
> > >  -- Artem
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrjälä
> > Intel
> 
> Best regards,
> Artem Mygaiev

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Artem Mygaiev]

On Wed, May 6, 2020 at 12:18 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Wed, May 06, 2020 at 12:04:22PM +0300, Artem Mygaiev wrote:
> > Hello Ville
> >
> > On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > > > Hello all
> > > >
> > > > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > > > controller [1]. I have already implemented a POC driver [2] which is working for
> > > > me, although there are still plenty of things to improve or fix, of course.
> > > >
> > > > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > > > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > > > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > > > by configuration.
> > >
> > > Does it do something to process the data that requires linearization
> > > or why does it care about the gamma applied to the data? In a typical
> > > use case the data is just passed through unless the user asks otherwise,
> > > so it doesn't matter much what gamma was used. Though most displays
> > > probably expect something resembling sRGB gamma by default, so that's
> > > presumably what most things generate, and images/videos/etc. pretty
> > > much always have gamma already applied when they are produced.
> > >
> >
> > Unfortunately the HW was designed in a way that when it is configured to 24-bit
> > RGB888 it expects sRGB and applies degamma automatically. It is not possible to
> > disable this, I've asked vendor and they confirmed this [1].
>
> So it always does degamma+gamma for no real reason? That shouldn't
> really matter (apart from potentially losing some precision in those
> conversions).
>

It always does only degamma (sRGB -> linear), so if you supply linear RGB it
will totally corrupt picture colors, e.g. this is how kmscube looks like:
https://github.com/klogg/fl2000_drm/issues/15

> >
> > The only workaround I could implement now is to switch it to 16-bit RGB565 and
> > perform framebuffer conversions in driver, similar to what
> > rm_fb_xrgb8888_to_rgb565() alike helpers do; but it would be still great to
> > understand whether it is possible to support sRGB.
> >
> > [1] https://github.com/FrescoLogic/FL2000/issues/42
> >
> > > >
> > > > Any pointers are greatly appreciated.
> > > >
> > > > [1] www.frescologic.com/product/single/fl2000
> > > > [2] https://github.com/klogg/fl2000_drm
> > > >
> > > > Best regards,
> > > >  -- Artem
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> >
> > Best regards,
> > Artem Mygaiev
>
> --
> Ville Syrjälä
> Intel

Best regards,
Artem Mygaiev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Ville Syrjälä]

On Wed, May 06, 2020 at 12:25:00PM +0300, Artem Mygaiev wrote:
> On Wed, May 6, 2020 at 12:18 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Wed, May 06, 2020 at 12:04:22PM +0300, Artem Mygaiev wrote:
> > > Hello Ville
> > >
> > > On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > > > > Hello all
> > > > >
> > > > > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > > > > controller [1]. I have already implemented a POC driver [2] which is working for
> > > > > me, although there are still plenty of things to improve or fix, of course.
> > > > >
> > > > > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > > > > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > > > > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > > > > by configuration.
> > > >
> > > > Does it do something to process the data that requires linearization
> > > > or why does it care about the gamma applied to the data? In a typical
> > > > use case the data is just passed through unless the user asks otherwise,
> > > > so it doesn't matter much what gamma was used. Though most displays
> > > > probably expect something resembling sRGB gamma by default, so that's
> > > > presumably what most things generate, and images/videos/etc. pretty
> > > > much always have gamma already applied when they are produced.
> > > >
> > >
> > > Unfortunately the HW was designed in a way that when it is configured to 24-bit
> > > RGB888 it expects sRGB and applies degamma automatically. It is not possible to
> > > disable this, I've asked vendor and they confirmed this [1].
> >
> > So it always does degamma+gamma for no real reason? That shouldn't
> > really matter (apart from potentially losing some precision in those
> > conversions).
> >
> 
> It always does only degamma (sRGB -> linear), so if you supply linear RGB it
> will totally corrupt picture colors, e.g. this is how kmscube looks like:
> https://github.com/klogg/fl2000_drm/issues/15

That doesn't really make sense to me. You never feed linear data to
actual displays.

> 
> > >
> > > The only workaround I could implement now is to switch it to 16-bit RGB565 and
> > > perform framebuffer conversions in driver, similar to what
> > > rm_fb_xrgb8888_to_rgb565() alike helpers do; but it would be still great to
> > > understand whether it is possible to support sRGB.
> > >
> > > [1] https://github.com/FrescoLogic/FL2000/issues/42
> > >
> > > > >
> > > > > Any pointers are greatly appreciated.
> > > > >
> > > > > [1] www.frescologic.com/product/single/fl2000
> > > > > [2] https://github.com/klogg/fl2000_drm
> > > > >
> > > > > Best regards,
> > > > >  -- Artem
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> > >
> > > Best regards,
> > > Artem Mygaiev
> >
> > --
> > Ville Syrjälä
> > Intel
> 
> Best regards,
> Artem Mygaiev

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Artem Mygaiev]

On Wed, May 6, 2020 at 12:33 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Wed, May 06, 2020 at 12:25:00PM +0300, Artem Mygaiev wrote:
> > On Wed, May 6, 2020 at 12:18 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Wed, May 06, 2020 at 12:04:22PM +0300, Artem Mygaiev wrote:
> > > > Hello Ville
> > > >
> > > > On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
> > > > <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > > > > > Hello all
> > > > > >
> > > > > > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > > > > > controller [1]. I have already implemented a POC driver [2] which is working for
> > > > > > me, although there are still plenty of things to improve or fix, of course.
> > > > > >
> > > > > > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > > > > > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > > > > > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > > > > > by configuration.
> > > > >
> > > > > Does it do something to process the data that requires linearization
> > > > > or why does it care about the gamma applied to the data? In a typical
> > > > > use case the data is just passed through unless the user asks otherwise,
> > > > > so it doesn't matter much what gamma was used. Though most displays
> > > > > probably expect something resembling sRGB gamma by default, so that's
> > > > > presumably what most things generate, and images/videos/etc. pretty
> > > > > much always have gamma already applied when they are produced.
> > > > >
> > > >
> > > > Unfortunately the HW was designed in a way that when it is configured to 24-bit
> > > > RGB888 it expects sRGB and applies degamma automatically. It is not possible to
> > > > disable this, I've asked vendor and they confirmed this [1].
> > >
> > > So it always does degamma+gamma for no real reason? That shouldn't
> > > really matter (apart from potentially losing some precision in those
> > > conversions).
> > >
> >
> > It always does only degamma (sRGB -> linear), so if you supply linear RGB it
> > will totally corrupt picture colors, e.g. this is how kmscube looks like:
> > https://github.com/klogg/fl2000_drm/issues/15
>
> That doesn't really make sense to me. You never feed linear data to
> actual displays.
>

I have a display with gamma 1.0 (as populated in EDID) which I assume means
linear gamma (am I wrong here?) which is connected to FL2000 dongle, so there is
no gamma applied after de-gamma.

But after further analysis I noticed that the problem is not the colorspace, HW
expects swapped 32-bit dwords in fbuffer. Somehow I completely overlooked this
when was working on original implementation.

Sorry for causing confusion - this is not the area I understand well enough, I
must admit.

> >
> > > >
> > > > The only workaround I could implement now is to switch it to 16-bit RGB565 and
> > > > perform framebuffer conversions in driver, similar to what
> > > > rm_fb_xrgb8888_to_rgb565() alike helpers do; but it would be still great to
> > > > understand whether it is possible to support sRGB.
> > > >
> > > > [1] https://github.com/FrescoLogic/FL2000/issues/42
> > > >
> > > > > >
> > > > > > Any pointers are greatly appreciated.
> > > > > >
> > > > > > [1] www.frescologic.com/product/single/fl2000
> > > > > > [2] https://github.com/klogg/fl2000_drm
> > > > > >
> > > > > > Best regards,
> > > > > >  -- Artem
> > > > > > _______________________________________________
> > > > > > dri-devel mailing list
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > >
> > > > > --
> > > > > Ville Syrjälä
> > > > > Intel
> > > >
> > > > Best regards,
> > > > Artem Mygaiev
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> >
> > Best regards,
> > Artem Mygaiev
>
> --
> Ville Syrjälä
> Intel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best regards,
Artem Mygaiev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Ville Syrjälä]

On Wed, May 06, 2020 at 04:54:08PM +0300, Artem Mygaiev wrote:
> On Wed, May 6, 2020 at 12:33 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Wed, May 06, 2020 at 12:25:00PM +0300, Artem Mygaiev wrote:
> > > On Wed, May 6, 2020 at 12:18 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Wed, May 06, 2020 at 12:04:22PM +0300, Artem Mygaiev wrote:
> > > > > Hello Ville
> > > > >
> > > > > On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
> > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > >
> > > > > > On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > > > > > > Hello all
> > > > > > >
> > > > > > > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > > > > > > controller [1]. I have already implemented a POC driver [2] which is working for
> > > > > > > me, although there are still plenty of things to improve or fix, of course.
> > > > > > >
> > > > > > > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > > > > > > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > > > > > > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > > > > > > by configuration.
> > > > > >
> > > > > > Does it do something to process the data that requires linearization
> > > > > > or why does it care about the gamma applied to the data? In a typical
> > > > > > use case the data is just passed through unless the user asks otherwise,
> > > > > > so it doesn't matter much what gamma was used. Though most displays
> > > > > > probably expect something resembling sRGB gamma by default, so that's
> > > > > > presumably what most things generate, and images/videos/etc. pretty
> > > > > > much always have gamma already applied when they are produced.
> > > > > >
> > > > >
> > > > > Unfortunately the HW was designed in a way that when it is configured to 24-bit
> > > > > RGB888 it expects sRGB and applies degamma automatically. It is not possible to
> > > > > disable this, I've asked vendor and they confirmed this [1].
> > > >
> > > > So it always does degamma+gamma for no real reason? That shouldn't
> > > > really matter (apart from potentially losing some precision in those
> > > > conversions).
> > > >
> > >
> > > It always does only degamma (sRGB -> linear), so if you supply linear RGB it
> > > will totally corrupt picture colors, e.g. this is how kmscube looks like:
> > > https://github.com/klogg/fl2000_drm/issues/15
> >
> > That doesn't really make sense to me. You never feed linear data to
> > actual displays.
> >
> 
> I have a display with gamma 1.0 (as populated in EDID) which I assume means
> linear gamma (am I wrong here?) which is connected to FL2000 dongle, so there is
> no gamma applied after de-gamma.

Never seen one like that myself IIRC.

Hmm. Looks like edid-decode (assuming that's what you used) decodes a 
value of 0xff as 1.0 for EDID v1.3 and older. That may be what's
happening in your case. Unfortunately the spec only says ""If set to
FFh, the gamma value is not defined here." without any further hint
as to where it might actually be defined. I think the only other
place we know of is the DispID ext block. Do you have one of those?
I suspect DispID might require the EDID to be v1.4 though.

Perhaps edid-decode should just say gamma is "undefined" or something 
in this case...

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Ville Syrjälä]

On Thu, May 07, 2020 at 09:07:59AM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 04:54:08PM +0300, Artem Mygaiev wrote:
> > On Wed, May 6, 2020 at 12:33 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Wed, May 06, 2020 at 12:25:00PM +0300, Artem Mygaiev wrote:
> > > > On Wed, May 6, 2020 at 12:18 PM Ville Syrjälä
> > > > <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > On Wed, May 06, 2020 at 12:04:22PM +0300, Artem Mygaiev wrote:
> > > > > > Hello Ville
> > > > > >
> > > > > > On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
> > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > >
> > > > > > > On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > > > > > > > Hello all
> > > > > > > >
> > > > > > > > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > > > > > > > controller [1]. I have already implemented a POC driver [2] which is working for
> > > > > > > > me, although there are still plenty of things to improve or fix, of course.
> > > > > > > >
> > > > > > > > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > > > > > > > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > > > > > > > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > > > > > > > by configuration.
> > > > > > >
> > > > > > > Does it do something to process the data that requires linearization
> > > > > > > or why does it care about the gamma applied to the data? In a typical
> > > > > > > use case the data is just passed through unless the user asks otherwise,
> > > > > > > so it doesn't matter much what gamma was used. Though most displays
> > > > > > > probably expect something resembling sRGB gamma by default, so that's
> > > > > > > presumably what most things generate, and images/videos/etc. pretty
> > > > > > > much always have gamma already applied when they are produced.
> > > > > > >
> > > > > >
> > > > > > Unfortunately the HW was designed in a way that when it is configured to 24-bit
> > > > > > RGB888 it expects sRGB and applies degamma automatically. It is not possible to
> > > > > > disable this, I've asked vendor and they confirmed this [1].
> > > > >
> > > > > So it always does degamma+gamma for no real reason? That shouldn't
> > > > > really matter (apart from potentially losing some precision in those
> > > > > conversions).
> > > > >
> > > >
> > > > It always does only degamma (sRGB -> linear), so if you supply linear RGB it
> > > > will totally corrupt picture colors, e.g. this is how kmscube looks like:
> > > > https://github.com/klogg/fl2000_drm/issues/15
> > >
> > > That doesn't really make sense to me. You never feed linear data to
> > > actual displays.
> > >
> > 
> > I have a display with gamma 1.0 (as populated in EDID) which I assume means
> > linear gamma (am I wrong here?) which is connected to FL2000 dongle, so there is
> > no gamma applied after de-gamma.
> 
> Never seen one like that myself IIRC.
> 
> Hmm. Looks like edid-decode (assuming that's what you used) decodes a 
> value of 0xff as 1.0 for EDID v1.3 and older. That may be what's
> happening in your case. Unfortunately the spec only says ""If set to
> FFh, the gamma value is not defined here." without any further hint
> as to where it might actually be defined. I think the only other
> place we know of is the DispID ext block. Do you have one of those?
> I suspect DispID might require the EDID to be v1.4 though.

Actually just found two ways an extension block might specify: 
Display Information Extension (DI-EXT), and Display Transfer
Characteristics Data Block (DTCDB) as part of the CEA ext block.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about sRGB framebuffer support

[Artem Mygaiev]

On Thu, May 7, 2020 at 9:18 AM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, May 07, 2020 at 09:07:59AM +0300, Ville Syrjälä wrote:
> > On Wed, May 06, 2020 at 04:54:08PM +0300, Artem Mygaiev wrote:
> > > On Wed, May 6, 2020 at 12:33 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Wed, May 06, 2020 at 12:25:00PM +0300, Artem Mygaiev wrote:
> > > > > On Wed, May 6, 2020 at 12:18 PM Ville Syrjälä
> > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > >
> > > > > > On Wed, May 06, 2020 at 12:04:22PM +0300, Artem Mygaiev wrote:
> > > > > > > Hello Ville
> > > > > > >
> > > > > > > On Wed, May 6, 2020 at 10:45 AM Ville Syrjälä
> > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > > > > > > > > Hello all
> > > > > > > > >
> > > > > > > > > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > > > > > > > > controller [1]. I have already implemented a POC driver [2] which is working for
> > > > > > > > > me, although there are still plenty of things to improve or fix, of course.
> > > > > > > > >
> > > > > > > > > So far I have one thing that I somehow cannot find in DRM/KMS documentation or
> > > > > > > > > existing drivers: how to tell the system that HW expects sRGB (i.e. non-linear)
> > > > > > > > > color encoding in framebuffers? This is a HW limitation that I cannot influence
> > > > > > > > > by configuration.
> > > > > > > >
> > > > > > > > Does it do something to process the data that requires linearization
> > > > > > > > or why does it care about the gamma applied to the data? In a typical
> > > > > > > > use case the data is just passed through unless the user asks otherwise,
> > > > > > > > so it doesn't matter much what gamma was used. Though most displays
> > > > > > > > probably expect something resembling sRGB gamma by default, so that's
> > > > > > > > presumably what most things generate, and images/videos/etc. pretty
> > > > > > > > much always have gamma already applied when they are produced.
> > > > > > > >
> > > > > > >
> > > > > > > Unfortunately the HW was designed in a way that when it is configured to 24-bit
> > > > > > > RGB888 it expects sRGB and applies degamma automatically. It is not possible to
> > > > > > > disable this, I've asked vendor and they confirmed this [1].
> > > > > >
> > > > > > So it always does degamma+gamma for no real reason? That shouldn't
> > > > > > really matter (apart from potentially losing some precision in those
> > > > > > conversions).
> > > > > >
> > > > >
> > > > > It always does only degamma (sRGB -> linear), so if you supply linear RGB it
> > > > > will totally corrupt picture colors, e.g. this is how kmscube looks like:
> > > > > https://github.com/klogg/fl2000_drm/issues/15
> > > >
> > > > That doesn't really make sense to me. You never feed linear data to
> > > > actual displays.
> > > >
> > >
> > > I have a display with gamma 1.0 (as populated in EDID) which I assume means
> > > linear gamma (am I wrong here?) which is connected to FL2000 dongle, so there is
> > > no gamma applied after de-gamma.
> >
> > Never seen one like that myself IIRC.
> >
> > Hmm. Looks like edid-decode (assuming that's what you used) decodes a
> > value of 0xff as 1.0 for EDID v1.3 and older. That may be what's
> > happening in your case. Unfortunately the spec only says ""If set to
> > FFh, the gamma value is not defined here." without any further hint
> > as to where it might actually be defined. I think the only other
> > place we know of is the DispID ext block. Do you have one of those?
> > I suspect DispID might require the EDID to be v1.4 though.
>
> Actually just found two ways an extension block might specify:
> Display Information Extension (DI-EXT), and Display Transfer
> Characteristics Data Block (DTCDB) as part of the CEA ext block.
>

First, I must reiterate that problem is solved for me, I was wrong in my
assumption that it has to do smth. with gamma, it was plain word order
misalignment. Thank you for support!

Just to close the topic with "weird" gamma 1.o display please see below the raw
EDID with my comments (parsed according to VESA-EEDID-A2):

00 FF FF FF FF FF FF 00  - header
04 81 - manufacturer
04 00 - product
01 00 00 00 - serial
01 - week
11 - year
01 03 - edid 1.3
80 - video input: digital, color depth undefined, interface undefined
0F - 15cm width
0A - 10cm height
00 - Gamma 1.0 (but value 0?)
0A - feature support: RGB 4:4:4 & YCrCb 4:4:4, preferred timing has details
00 00 00 00 00 00 00 00 00 00 - color characteristics empty
00 00 00 - established timings empty
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 - unused standard timings 1
80 0C 20 80 30 E0 2D 10 28 30 D3 00 6C 44 00 00 00 18 - preferred timings
00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - unused descriptor
00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - unused descriptor
00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - unused descriptor
00 - no extensions
17 - crc

Best regards,
Artem Mygaiev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel