On 2018-05-03 08:31 PM, sunpeng.li at amd.com wrote: > > 3. The three color management properties (Degamma LUT, Color Transform Matrix > (CTM), and Gamma LUT) are hard-coded into the DDX driver, to be listed (as > disabled) regardless of whether a CRTC is attached on the output, or whether > the kernel driver supports it. > > * If kernel driver does not support color management, the properties will > remain disabled. A `xrandr --set` will then error. Is it really useful to expose these properties to clients if the kernel doesn't support them? > 4. Color properties are now *staged* inside the driver-private CRTC object. > This allows us to *push* the properties into kernel DRM (and consequently > into hardware) whenever there is a need. > > * Along with staging and pushing, an *update* function is used to notify > RandR to update the color properties listed on outputs. This can be used > when `xrandr --auto` enables a CRTC on an output, and the output need to > reflect the CRTC's color properties. I feel like some of this is a bit more complicated than necessary. This is how I'd envision it working: In drmmode_crtc_init, query the properties from the kernel, more or less as done in this series. In drmmode_output_create_resources, create the output properties (or not, per above) based on output->crtc, or if that is NULL, based on xf86_config->crtc[0]. In drmmode_output_get_property, if output->crtc != NULL, update the RandR property value from it, otherwise set it to a dummy value. In drmmode_output_set_property, if output->crtc != NULL, update its property value, otherwise do nothing. Push the CRTC's property values to the kernel in drmmode_crtc_gamma_do_set and drmmode_output_set_property (or maybe just call the former from the latter when one of these properties are changed). Is that feasible? If patch 13 still exists after this, can you squash it into the earlier patches adding the code? > * When using libXrandr to set the CTM property, 16bit format is used. Ideally > we should use 64bit format, since the CTM consists of 9x64bit fixed-point > values. However, it isn't recognized by XRRChangeOutputProperty as a valid > format. 32 bit could work, since the CTM values are S31.32 fixed-point. > However, using this format corrupts the data once it gets to xserver. On > first glance, it may be the cast to long within XRRChangeOutputProperty, in > addition to compiling 64 bit (shouldn't it use int32_t instead?). For historical reasons, Xlib uses long for 32-bit values, so you have to pad each 32-bit value to a long. XCB shouldn't be affected by this. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
