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
