> On Wed, 26 Mar 2025 06:03:27 +0000 > "Murthy, Arun R" <arun.r.mur...@intel.com> wrote: > > > > On Wed, 19 Mar 2025 12:08:15 +0000 > > > "Murthy, Arun R" <arun.r.mur...@intel.com> wrote: > > > > > > > > On Mon, 3 Mar 2025 13:23:42 +0530 "Murthy, Arun R" > > > > > <arun.r.mur...@intel.com> wrote: > > > > > > > > > > > On 20-02-2025 21:20, Pekka Paalanen wrote: > > > > > > > On Wed, 19 Feb 2025 09:28:51 +0530 "Murthy, Arun R" > > > > > > > <arun.r.mur...@intel.com> wrote: > > > > > > ... > > > > > > > > > Hi Pekka, > > > > > > Sorry got getting back late on this. > > > > > > I totally agree that the UAPI should not be any hardware > > > > > > specific and have taken care to get rid of such if any. > > > > > > Here we are just exposing the histogram data and what point is > > > > > > the histogram generated is out of the scope. > > > > > > > > > > It's not out of scope. Understanding exactly at what point the > > > > > histogram is generated in the KMS pixel pipeline is paramount to > > > > > being able to use the results correctly - how it relates to the > framebuffers' > > > > > contents and KMS pixel pipeline configuration. > > > > > > > > > > > > > While working around this comment, it looks to be quite > > > > challenging to address this comment and agree that this will have > > > > to be addressed and is important for the user to know at which > > > > point in the pixel pipeline configuration the histogram is generated. > > > > I can think of 2 options on addressing this. > > > > > > > > 1. Have this documented in the driver. Since this can vary on > > > > each vendor hardware, can have this documented in the drivers or ReST > document. > > > > > > > > > > Hi Arun, > > > > > > this is not acceptable in KMS, because it requires userspace to have > > > code that depends on the hardware revision or identity. When new > > > hardware appears, it will not be enough to update the drivers, one > > > will also need to update userspace. There currently is no userspace > > > "standard KMS library" to abstract all drivers further, like there is > > > libcamera > and Mesa. > > > > > > > 2. Maybe have a bitmapping like we have it for histogram_mode. > > > > Define user readable macros for that. > > > > Ex: CC1_DEGAMMA_HIST_CC2 > > > > In this case histogram is between the two color conversion > > > > hardware block in the pixel pipeline. > > > > This macro will have to be defined on need basis and define a u32 > > > > variable for this bit manipulation. > > > > > > This one still has problems in that some hardware may not have all > > > the non- HIST elements or not in the same order. It's a better > > > abstraction than option 1, but it's still weak. > > > > > > I can see one solid solution, but it won't be usable for quite some > > > time I > > > suppose: > > > > > > https://lore.kernel.org/dri-devel/20241220043410.416867-5- > > > alex.h...@amd.com/ > > > > > > The current work on the color pipelines UAPI is concentrated on the > > > per-plane operations. The idea is that once those are hashed out, > > > the same design is applied to CRTCs as well, deprecating all > > > existing CRTC color processing properties. A histogram processing > > > element could be exposed as a colorop object, and its position in a > > > CRTC color pipeline represents the point where the histogram is collected. > > > > > > That would be the best possible UAPI design on current knowledge in > > > my opinion. > > > > > Yes this would be the best design, but looking into the timeline for > > this CRTC color pipeline can we proceed with this as in interim solution. > > Once we have the CRTC color pipeline in drm, will rebase this > > histogram to make use of the pipeline. > > We can also take up the crtc color pipeline and will also start > > contributing to get things faster but since there is not timeline > > defined for that activity, would it be viable to go ahead with option2 as in > interim solution? > > Hi Arun, > > I think that's something the DRM maintainers should chime in on. > > > Thanks, > pq > drm Maintainers, any inputs on this?
Thanks and Regards, Arun R Murthy --------------------
