[PATCHv10 00/10] Display Global Histogram

[Raag Jadav]

On Mon, Dec 09, 2024 at 10:18:42AM -0800, Matt Roper wrote:
> On Mon, Dec 09, 2024 at 07:43:55PM +0200, Raag Jadav wrote:
> > On Mon, Dec 09, 2024 at 08:57:56AM -0800, Matt Roper wrote:
> > > On Mon, Dec 09, 2024 at 09:54:54PM +0530, Arun R Murthy wrote:
> > > > Display histogram is a hardware functionality where a statistics for 'x'
> > > > number of frames is generated to form a histogram data. This is notified
> > > > to the user via histogram event. Compositor will then upon sensing the
> > > > histogram event will read the histogram data from KMD via crtc property.
> > > > A library can be developed to take this generated histogram as an
> > > > input and apply some algorithm to generate an Image EnhancemenT(IET).
> > > > This is further fed back to the KMD via crtc property. KMD will use this
> > > > IET as a multiplicand factor to multiply with the incoming pixels at the
> > > > end of the pipe which is then pushed onto the display.
> > > > 
> > > > One such library Global Histogram Enhancement(GHE) will take the histogram
> > > > as input and applied the algorithm to enhance the density and then
> > > > return the enhanced factor. This library can be located @
> > > > https://github.com/intel/ghe
> > > > 
> > > > The corresponding mutter changes to enable/disable histogram, read the
> > > > histogram data, communicate with the library and write the enhanced data
> > > > back to the KMD is also pushed for review at https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3873
> > > > and https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3873/diffs?commit_id=270808ca7c8be48513553d95b4a47541f5d40206
> > > > The IGT changes for validating the histogram event and reading the
> > > > histogram is also pushed for review at https://patchwork.freedesktop.org/series/135789/
> > > 
> > > I think other people have already asked this on previous postings of
> > > these patches, but please don't try to manually hack the version numbers
> > > within a series.  What you just posted has "PATCHv10" on the cover
> > > letter, "PATCHv2" on one patch, "PATCHv3" on three patches, and the rest
> > > are unversioned "PATCH."  The general expectation these days is that
> > > versioning in the subject applies to the series as a whole, not the
> > > individual patches, so this causes a lot of confusion.  Posting like you
> > > did here also wrecks havoc on a lot of the tools people use to manage
> > > and compare series like the "b4" tool.
> > > 
> > > When generating and sending a new series, you should just do something
> > > like "git format-patch -v10 ..." so that the proper "v10" numbering is
> > > automatically applied to all the patches and we don't wind up with this
> > > strange jumble.
> > 
> > Isn't that the starting point?
> > 
> > https://kernelnewbies.org/FirstKernelPatch -> "Versioning patchsets"
> 
> That section is explaining that the descriptive changelogs for updated
> series can either be placed in the cover letter or in the individual
> patches; I don't see anything about going back and editing the "[PATCH"
> prefix of the subject line that was generated.  You generate the new
> copy of all the patches (and the cover letter) with one execution of
> "git format-patch," so whatever version number is generated should be
> consistent and correct as a series-wide version without editing.

Yes, that's what I meant above (which is explained with an example).

Raag