When you did such in code, did you do it with a function call that communicated the color characteristics, also known as “the profile”, of the image you provided? If not, then the OS doesn’t have the information it needs to change anything with respect to color. That hardware LUT can’t do this by itself, it needs the preparatory work of the application software’s color transform as the input for what it does.
My point is that the conversion from dt’s internal colorspace to display is not so simple as you’re thinking, and depending on the profile, part is done in the application, and part may be done in the video card. To reliably remove that from the pipe and just send whatever dt has internally to the display, you need to remove the display profile from the OS, so it doesn’t load the LUT into the video card AND it doesn’t make the rest of the profile available to dt…
The Wayland color managment thread is the only discourse I know of about including what you think is going on in an OS, and they’re a good ways away from having an implementation…
I wrote this a few weeks ago:
In the graphic, the “Convert to Display Profile” is what we’re teasing apart here.