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 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.

-- 
Ville Syrjälä
Intel