<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> Hi Rob, Alex, Ben, All J<o:p></o:p> <o:p> </o:p> I am Shashank Sharma, from Linux display team Intel, Bangalore.<o:p></o:p> We are planning to add a color management extension in the existing I915 driver, for Intel HWs.<o:p></o:p> Plan was to provide a color correction and enhancement interface for any Linux based userspace, based on various HW capabilities. <o:p></o:p> <o:p> </o:p> We are now thinking that if we can generalize this implementation, in such a way that other drivers can also utilize this, this idea can act as an extension to the DRM framework itself.<o:p></o:p> Based on that thought, We have prepared a design for the same, and a rough implementation based on this design. <o:p></o:p> <o:p> </o:p> Would you all be kind enough to have a look at this design, and give us some feedback, so that we can implement this in a way best suitable to most of the drivers ? <o:p></o:p> We have gone through few rounds of design discussions internally (design contributors, reviewers in CC), and we all are moreover agree on the design (few comments still in progress). <o:p></o:p> <o:p> </o:p> The highlights of the design:<o:p></o:p> <![if !supportLists]>1. <![endif]>The color correction capabilities of a HW are being registered as a DRM property of a CRTC / Plane (depending on a HW)<o:p></o:p> <![if !supportLists]>2. <![endif]>Properties will be of blob type. <o:p></o:p> <![if !supportLists]>3. <![endif]>New data structures will be added in DRM layer, to encoder and decode color correction and enhancement data. <o:p></o:p> <![if !supportLists]>4. <![endif]>The color correction DRM properties would look like :<o:p></o:p> <![if !supportLists]>a. <![endif]>Palette correction / programming based color properties (like gamma correction). This can support various coefficients counts and correction values, based on the underneath HW.<o:p></o:p> <![if !supportLists]>b. <![endif]>Color transformation matrix based color correction (CSC, wide and narrow gamut mapping)<o:p></o:p> <![if !supportLists]>c. <![endif]>Plane level corrections like gamma correction, hue, saturation, contrast and brightness. <o:p></o:p> <![if !supportLists]>d. <![endif]>One blob type property to showcase the color correction capabilities to the userspace, superset of all other color correction properties. <o:p></o:p> <![if !supportLists]>5. <![endif]>The driver’s init function can create the superset color property, and show its color capabilities to the userspace. <o:p></o:p> <![if !supportLists]>6. <![endif]>Userspace can query the current color correction Or apply a new color correction using a set/get property interface. <o:p></o:p> <o:p> </o:p> Please find the detailed design, in this shared google document: <o:p></o:p> <a href="https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/">https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/</a> <o:p></o:p> Please feel free to add more people in the design discussion, once we have some basic agreement on the design, we will share the patches in dri-devel level. <o:p></o:p> <o:p> </o:p> Regards<o:p></o:p> Shashank<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html>