Aha coming to this. This definitely needs some ifdefs regarding wayland so it's not enabled when in wayland mode (also runtime checks too as well).

Now the question really is... do we REALLY want to do this this way? So... my experience with the randr gamma controls is they are limited in resolution. So that means that they use an integer lookup table with ... 8 bits. so if you drop toe.g 1/4 brightness you end up with banding in the image as you now only have 64 levels of r, g, b instead of 256. i looked at this quite a while back and decided for now at least not to do this. The quality is pretty poor. Now this does bring up a bigger topic of general image manipulation. Like not just darkening the image but also color-correcting, doing blue-light filtering and other such things.

Why did you do this? for external monitors? That has been solved via ddcutil now where we actually control the monitor itself.

If we're going to end up doing a filter object that modifies RGB for darkening or any other number of image corrections/transforms, we could improve quality by doing dithering in GLSL shaders (for gpu rendered stuff this will actually then solve the above quality issue as gpu's do their intermediate rendering in floating point so if we add some noise we can actually effectively get more color resolution by noise-like dithering). This then allows brightness, contrast, blue light, color temp and other stuff at the rendering level (but the downside is it's an extra hop for rendering through an FBO so extra overhead).