You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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..100 interval 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 xcalib invocation like e.g. gstreamer does. Imagine writing xcalib -a -c ! -a -co 50 would dry-run consecutively xcalib -a -c and then xcalib -a -co 50 internally but thanks to the "deferred" behavior it would apply to the screen only the resulting numbers effectively avoiding the flicker.
WDYT?
The text was updated successfully, but these errors were encountered:
dumblob
changed the title
Remove the 1..100 contrast limitation
Remove the 1..100 contrast limitation to avoid flicker
Mar 15, 2023
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.)
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 😉 (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.
I am a long time user of
xcalib
and for years I have been using the hack to first runxcalib -c
and thenxcalib -a -v | ...
and thenxcalib -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:
1..100
interval limitation and allow negative numbers on input (i.e. change the interval to-100..100
).xcalib
invocation like e.g. gstreamer does. Imagine writingxcalib -a -c ! -a -co 50
would dry-run consecutivelyxcalib -a -c
and thenxcalib -a -co 50
internally but thanks to the "deferred" behavior it would apply to the screen only the resulting numbers effectively avoiding the flicker.WDYT?
The text was updated successfully, but these errors were encountered: