Responses below: On Wed, 2026-09-23 at 13:23 -0300, Daniel Campos Ramos wrote: > On Wed, 2026-09-23 at 12:13 -0400, [email protected] wrote: > > You need to either tag your work with Assisted-by: if it is > > generated > > by an LLM. If you did the right thing and wrote it by hand and just > > used these tools for analysis, that's fine. > > > > FWIW, If this was entirely generated by an LLM, then this is quite > > a > > lot of work and I'm very hesitant to review this. Going off: > > > > https://github.com/danielcamposramos/awesome-linux-hdr > > > > I am very concerned just about all of the results here came out of > > an > > LLM, according to the LLM generated provenance file, which means an > > actual real person with experience working on this needs to go back > > and > > verify that all of this is correct. That is a lot of work, and the > > idea > > that my review comments are just going to get fed back into an LLM > > are > > not remotely encouraging to the effort of having to go through and > > have > > a real person look this over. > > Thank you, Lyude, both points are fair. > > The code was not written by hand: an AI partner wrote it under my > direction, and I left out the Assisted-by tag the kernel > documentation asks for. I will resend with it on every patch, and the > Deep Color series gets the same. > Sorry for that detail: I disclosed it in the cover letter body, but > the tag belongs on each patch. > For the record, the tools: both series were worked on inside Claude > Code CLI and Codex CLI by several AI partners, Moonshot's Kimi, > Zhipu's GLM, Anthropic's Claude, and OpenAI's GPT Astra and GPT Sol. > > What was mine: I found the problem on my own bench (full-range pixels > to a Sony without a VCDB), set the design rules (follow > drm_hdmi_state_helper.c, use NVIDIA's open NVKMS as the hardware > reference), and ran every hardware test myself, 25 configurations, > checking bars and levels on the set. > > The OCSC1 values were checked against NVKMS, not taken from the > model's memory; the BT.601/709/2020 re-derivation was also done with > the AI. > > On awesome-linux-hdr: it is an index of links, not the evidence for > this series. > Its provenance file names the AI partners for the source surveys; the > hardware results are my bench measurements, and the logs for these > patches are run27 and run28 in sony-bravia-linux (tools/stereo- > modeset).
I'm happy to look at logs if I have something specifically I would like to verify, but verifying the entirety of how this works from a bunch of logs and measurements along with knowing whether we're missing anything from this implementation that would lead to regressions (I already know we are missing some things, which I will mention below) is more or less the same as having to go and just do the work by hand myself. At which point, I would strongly prefer someone to just implement the findings of those results by hand. We also have someone who has been working on these features on nouveau's side already without the help of an LLM, and their work is pretty much almost complete already and handles the missing bits properly including: * Implementing IMP both for atomic checking and for tile allocation on some tegra platforms * Implementing display bandwidth allocation. This is needed for deep color with higher resolution displays, which will crash the GPU otherwise upon trying to set them (which I think would be the case with this patch series). * Enabling DSC and FRL on HDMI (also needed for higher res HDMI displays) We've already merged some of their work for this, in particular some of the work for fixing up blackwell and also reading HDR information from EDIDs. So I'm not really sure we want to use this work anyway, sorry about that! One last thing though: it's somewhat of a moot point now, but in the future: please consider just limiting your usage of LLM tooling for actually figuring out the details of how things work and then handle writing the code yourself after you go through the various openrm sources it points you to. If I had accepted this work, it would have taken a lot more time for me to actually get across the finish line and be comfortable with merging it then is really needed. There's a very hard limit as to the level of confidence anyone can have with LLM generated code without spending more time reviewing it then you would have if you wrote the code yourself, because you're now approaching your own code submissions from the narrow perspective of a reviewer and not its author. We do require people take responsibility for LLM submissions. It's easy to you take responsibility, but this is more complicated then just "yeah I'll try looking at it again if something breaks". To me, if the code is LLM generated, then the work in it's entirety needs to be of a size where the author can reasonably have the exact level of understanding they would have had if they wrote the code line by line themselves and also trudged through the actual OpenRM code they were looking at themselves. Otherwise, I have to be the one to do it in some form. And that means me taking responsibility for the possible fallout, and spending a _lot_ time then I would with a normal submission to get as close to the level of understanding as an author as I can and then take on the responsibility of dealing with the potential fallout of the changes myself, quite possibly on my own. FWIW: I think the approach that was taken recently with reverse- engineering how ray tracing/BVHs work on nvidia hardare is a great example of how these tools can be used without creating friction for maintainers. There was plenty of AI generated code there, but it was only given to us as a proof of concept with the expectation we might not actually use any of the code. Which meant we could try implementing it by hand and learn everything we can about the subject matter throughout that journey instead of trying to trudge through the LLM's code and hope very hope we don't miss or glance over anything. Just approaching stuff this way does genuinely provide a lot more confidence to maintainers, and does help to reduce the workload we have to deal with by making sure there's always a person reasonably in the loop. Otherwise we're struggling to make sure that's the case a lot more then before. > > I read review comments and answer them myself. > > Fixes will again be written with AI help, declared in each version, > and tested on the same bench before they go out. > > To make review cheaper, I can resend only patches 1 to 3 first (the > header, the head programming, and Broadcast RGB, which fixes the > visible range problem), or wait for whatever priority suits you or > suites better. Feel free to also include it, if you want. > > Daniel
