OpenICC
Remove the 1..100 contrast limitation to avoid flicker
I am a long time user of xcalib and for years I have been using the hack to first run xcalib -c and then xcalib -a -v | ... and then xcalib -a -co ... to simulate behavior of "percent points independent of the current state" instead of the current "percentage relative to the current state".
Now though I became too old to withstand the flickering due to xcalib -c.
Either of these solutions would do IMHO:
- Treat percentage as "percent points" instead of the current percentage of the current ICC/LUT state. Percent points would thus be an absolute scale all the time (not relative as they are now).
- Remove the
1..100interval limitation and allow negative numbers on input (i.e. change the interval to-100..100). - Allow deferred application of the resulting computation (i.e. "transactionally" without flickering) from a chain of operations in one
xcalibinvocation like e.g. gstreamer does. Imagine writingxcalib -a -c ! -a -co 50would dry-run consecutivelyxcalib -a -cand thenxcalib -a -co 50internally but thanks to the "deferred" behavior it would apply to the screen only the resulting numbers effectively avoiding the flicker.
WDYT?
Would it help to avoid flicker, when xcalib accepts a profile without VCGT + gamma arguments (-gammacor XXX -red ...)? Thus xcalib -c is not needed. (At the moment only xcalib vcgt.icc -gammacor XXX -red ... works without -a altering.)
Hi Kai! Sorry for not noticing your response.
Actually yes, getting rid of xcalib -c seems would solve my issue. It just seemed too much of a rework of xcalib to propose this solution :wink: (compared to the patch I have put together with a hot needle).
By the way, do you know about any similar initiative for Wayland? Missing xcalib and vibrant-cli are the major reasons why I am still staying with X.
Still not much up to date with Wayland. KDE and possibly other DE have (wayland?) tools integrated for night light switching and so on, which covers part of xcalib's functionality.