Question about sRGB framebuffer support

[Artem Mygaiev]

On Thu, May 7, 2020 at 9:18 AM Ville Syrjälä
<ville.syrjala at 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 at 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 at 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 at 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