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. Perhaps edid-decode should just say gamma is "undefined" or something in this case... -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
