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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
