You are not logged in.
Hi there, have a problem with my color schemas. When I start my computer everything is fine but when the screen has been in sleep mode and awakes everything is a little different, colors are a little foggier gray is less gray. So to say, everything looks a little whiter.
I'm using i3 as my WM and breeze is installed as theme for gtk2/3, no QT.
Searched and read a lot of documents about themes and use of colors but I'm unable to find why they change after a screen sleep.
For this purpose I have created a clean environment.Have setup a user with only the necessary config files like a i3 config and the below environment files.
Sometimes it wakes and all colors are right but most of the time they are off by a few tints lighter. I'm somehow baffled how this is possible and don't have a clue how it how it happens. After a few weeks of trying to figure this out I'm seeking help here...
First I thought it was my monitor and I still have suspicions that could be it but I'm definitely not sure and wouldn't know how to test it anyway..
Also I have tested some live iso's, archiso, archbang, mint and manjaro. Mint and Archbang ware okay, Manjaro didn't go to sleep so that didn't help and Archiso had the same problem.
My configs are basically right out of the wiki but if you need more than shown below just ask.
Showing a screenshot won't show the differences because the effect also influences the output, meaning both screenshots are the same! Making a photo of the screen don't show it very well either, the result however is very viable.
For completeness these are the configs used to make it happen.
.Xresources
xterm*termName: xterm-256color
xterm*faceName: Terminus:style=Regular:size=10
xterm*utf8: 2
xterm*saveLines: 1024
xterm*scrollBar: false
xterm*multiScroll: true
XTerm*VT100.background: #222222
XTerm*VT100.foreground: #ffffff
! Terminal colors
! black
*color0: #222222
*color8: #454545
! red
*color1: #9E5641
*color9: #CC896D
etc.gtkrc-2.0
gtk-theme-name="Breeze-Dark"
gtk-icon-theme-name="Faenza-Darker"
gtk-font-name="Sans 10"
gtk-cursor-theme-name="Faenza-Darker"
gtk-cursor-theme-size=0
gtk-toolbar-style=GTK_TOOLBAR_BOTH_HORIZ
gtk-toolbar-icon-size=GTK_ICON_SIZE_SMALL_TOOLBAR
gtk-enable-event-sounds=0
gtk-enable-input-feedback-sounds=0
gtk-xft-antialias=1
gtk-xft-hinting=1
gtk-xft-hintstyle="hintslight"
gtk-xft-rgba="rgb"
gtk-error-bell=0
gtk-application-prefer-dark-theme=1gtk-3.0/settings.ini
[Settings]
gtk-theme-name=Breeze-Dark
gtk-icon-theme-name=Faenza=Darker
gtk-font-name=Sans 10
gtk-cursor-theme-name=Faenza-Darker
gtk-cursor-theme-size=0
gtk-toolbar-style=GTK_TOOLBAR_BOTH_HORIZ
gtk-toolbar-icon-size=GTK_ICON_SIZE_SMALL_TOOLBAR
gtk-enable-event-sounds=0
gtk-enable-input-feedback-sounds=0
gtk-xft-antialias=1
gtk-xft-hinting=1
gtk-xft-hintstyle=hintslight
gtk-xft-rgba=rgb
gtk-application-prefer-dark-theme=1
gtk-error-bell=0i3 config + the next adaptions
# class-original border backgr. text indicator child_border
client.focused #444444 #222222 #ffffff #555555
client.focused_inactive #444444 #222222 #dddddd #000000
client.unfocused #444444 #222222 #aaaaaa #2d2d2d
client.urgent #FDF801 #222222 #FDF801 #900000
client.background #222222
# Start i3bar to display a workspace bar (plus the system information i3status
# finds out, if available)
bar {
status_command py3status
position top
strip_workspace_numbers yes
font pango:DejaVu Sans Mono, Terminus Bold Semi-Condensed 10
colors {
background #222222
statusline #999999
separator #666666
#border #backgr #text
focused_workspace #888888 #000000 #df8700
active_workspace #7B7D7B #df8700 #000000
inactive_workspace #333333 #000000 #666666
urgent_workspace #444444 #000000 #ffffaf
}
}Last edited by qinohe (2020-06-24 20:56:54)
Offline
Showing a screenshot won't show the differences because the effect also influences the output, meaning both screenshots are the same!
As I was reading, this was the diagnostic I was going to ask for. Your screenshots would indicate this has nothing to do with themes and it is not the colors that are different. Your backlight is just brighter after the sleep. Check the backlight brightness before and after.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks, I don't use anything to adjust brightness, it's set on the monitor..
Nothing has changed after a screen sleep for I have checked the values on the monitor after it.
If it is possible to check values in arch too, what tool do I need to check it? Sorry for asking I'm somehow a nitwit on this matter.
edit:if you would still like to see screenshots I'll upload them...
Last edited by qinohe (2020-06-23 20:46:55)
Offline
If it is possible to check values in arch too
That's what I was suggesting. Software processes couldn't change hardware settings, but they can change the backlight and related settings of the OS. Exactly where this is depends on your hardware. If you've never explored your sys filesystem, the following may help:
find -L /sys/class -maxdepth 4 -name brightness"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Right, I had already looked there:(
cat /sys/class/backlight/acpi_video0/actual_brightness
60This is before and after the screen sleep, nothing changes there.
So or it's properties are set elsewhere too or screen waking sets a value I'm not able to find anywhere...
Offline
Offline
@seth, thanks man. I can tell that had an enormous effect on my monitor(Dell-U2417H) anthracite became as dark as I have never seen before, absolutely beautiful, I'll set it in my xinitrc.
I have waited for a screen sleep before I reacted but everything is already so dark I may need to adjust my themes a little, but, I couldn't tell if it was hazier after waking...
For now I will mark as solved but after adjusting theme colors it could be off again, we'll see...
Thanks Trilby and seth, hope it stays solved;)
Offline
For people having this same issue, which should definitely be a few, these are my findings after trying this setting added to my xinitrc.
With the theme I use (breeze-dark) the screen starts way to dark, anthracite is almost black, too dark at least(tested on other high res. screen).
My system is never off and I only restart for kernel or a systemd upgrade. So after the first screen sleep colors are back to a state like you would start the system without this xrandr setting for the first time.
It's not optimal and I hope there will be a fix for it one-day but have my doubts since a kernel dev state they are doing it right and is a 'WONTFIX'.(#6), but I can live with it like this.
Offline
There's sth. off - your monitor (model+vendor?) either has full color range support or not.
I could see how the re-detection would fail, but enforcing a mode just fixes that and should™ not result in a "false" mode initially. This would imply that the output alters its color range support during the dpms.
For mitigation you could maybe "xset dpms force off" in your xinitrc (to trigger the dpms immediately instead of sitting around and waiting for the dpms to kick in atomatically)
Offline
Hi seth, thanks, already had a feeling it's not okay yet, I could however have lived with the situation. But now you come with a new possible solution lets try;)
My monitor is a Dell-U2417H and seems to work well??, at least I never have problems with it. It's connected trough HDMI, a cable change doesn't change anything as the devs already said in the bug report, but I have tried it. There has also been an HDMI switch on it with extra cable of course which also works, result is the same anyway.
I will add that setting to my xinitrc but should I remove the xrandr line or leave it like that?
Removed 'Solved' for now...
edit:
specs: https://www.dell.com/ae/business/p/dell … monitor/pd
Last edited by qinohe (2020-06-24 19:02:20)
Offline
Leave the xrandr line, you still want to enforce the color range - just that you also trigger the dpms event that aligns the enforced range w/ the actual output behavior.
The stupid tech sheet doesn't specify the color range and whether it's a 6bpc or 8bpc panel, but there's a suspicious "gamma" setting which can be either "PC" or "MAC" …
I'd check whether this value changes and also whether it has impact relevant to your situation.
Offline
Leave the xrandr line, you still want to enforce the color range - just that you also trigger the dpms event that aligns the enforced range w/ the actual output behavior.
Yes, dpms kicks in immediately and after waking the screen the result is the same as after a screen sleep. After a screen sleep the result is persistent.
The stupid tech sheet doesn't specify the color range and whether it's a 6bpc or 8bpc panel, but there's a suspicious "gamma" setting which can be either "PC" or "MAC" …
I'd check whether this value changes and also whether it has impact relevant to your situation.
It's not an Eizo;), but, nothing changes after screen sleep, xset q reports the same colors, I am however still uncomfortable on this matter, xset q reports
Colors:
default colormap: 0x22 BlackPixel: 0x0 WhitePixel: 0xffffffedit:
xrandr --verbose reports:
HDCP Content Type: HDCP Type0
supported: HDCP Type0, HDCP Type1
Content Protection: Undesired
supported: Undesired, Desired, Enabled
Colorspace: Default
supported: Default, RGB_Wide_Gamut_Fixed_Point, RGB_Wide_Gamut_Floating_Point, opRGB, DCI-P3_RGB_D65, BT2020_RGB, BT601_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, BT2020_CYCC, BT2020_YCC
max bpc: 12
range: (6, 12)
Broadcast RGB: Full
supported: Automatic, Full, Limited 16:235
audio: auto
supported: force-dvi, off, auto, on
link-status: Good
supported: Good, Bad
non-desktop: 0
range: (0, 1)Last edited by qinohe (2020-06-24 19:58:25)
Offline
I meant the setting in the monitors OSD. Color/Gamma/[PC|MAC]
Alternatively, see whether adjusting the gamma value w/ eg. xgamma or "xcalib -a -gc 1.4" changes anything in your favor. ("xcalib -c" resets the gamma ramps, values < 1 are less, > 1 more contrast; don't go too extreme)
Offline
Have played a little with the OSD, tried both 'PC' and 'MAC' RGB seems to be the best choice on both options, at least that's how I think about it, they seem to look the same...
I have also tried "xcalib -a -gc 1.4" which gives the result that looks about the same as starting the WM without 'xset dpms force off', seems default looks best for now.
Also tried a few pictures of which I know are good pictures, and I also tried 'Test card/Testbeeld/Testbild' which I have a good copy of, something like: https://en.wikipedia.org/wiki/Test_card
The testcard also seems to give a good result with the current settings. Of course, I don't have a 'screen spider' to check and set a perfect profile, but for now I'm very happy with the results.
So again, Thank you very much for the support, appreciate it;) and I owe you a beer!
Offline