On 2018-06-08 04:33 PM, Michel Dänzer wrote: > On 2018-06-08 12:21 AM, Leo Li wrote: >> On 2018-06-06 01:03 PM, Michel Dänzer wrote: >>> On 2018-06-06 06:01 PM, Michel Dänzer wrote: >>>> >>>> Running Xorg in depth 30[0] results in completely wrong colours >>>> (everything has a red tint) with current kernels. I think this is >>>> because DC now preserves the gamma LUT values, but xf86-video-amdgpu >>>> never sets them at depth 30, so the hardware is still using values for >>>> 24-bit RGB. >>> >>> Actually, looks like I made a mistake in my testing before; this issue >>> only occurs as of patch 6 of this series. >> >> It seems to be caused by legacy gamma being disabled on depth 30. When >> that's the case, the gamma_set() hook is set to null. RandR won't >> compute the legacy LUT, causing LUT interpolation/composition to spit >> out an invalid LUT. I verified this by commenting out the `pScrn->depth >> == 30` conditionals guarding the legacy gamma features (in pre_init, and >> mode_major). >> >> I'm not certain of the best way to fix this. Would it make sense to >> enable legacy gamma on 30bpp if non-legacy is supported? We can do that >> since legacy gamma gets interpolated/composed to non-legacy. >> >> However, it doesn't make sense when you look at the LUT size, since >> legacy gamma supports only 256 elements (should be 1024 on depth 30?) >> In which case we can skip interpolation/composition altogether. > > Right, we'll probably need to increase the RandR LUT size as well at > depth 30. > > > Anyway, let's not hold up this patch series over this. Simply keep all > this code disabled (i.e. same as if the kernel didn't expose the > properties) at depth 30 for now. Or, if there's a straightforward way to expose the properties while ignoring the RandR LUT at depth 30, that's another option for this series. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
