Compatibility with xscreensaver
Closed this issue · 11 comments
At present and with default config, xscreensaver disables blugon when a screensaver is activated. Is there a way to have blugon run on top of screensavers?
I tried xscreensaver
and previewed some screensavers and didn't notice anything bad.
I think it behaves badly with dpms. I use xscreensaver, but only for blanking my screens and putting them into powersave. IIRC the screen resets to default settings when it powers back up. Haven't tested/verified that any of this is 100%
I really have no idea how I could fix that with blugon, but you can maybe run blugon --once
from a script if the reset comes consistently with a specific event.
Actually it works fine with dpms or when previewing screensavers, the issue is when screensavers actually get triggered.
Steps to reproduce:
- Run
xscreensaver-demo
from terminal - click File > Blank screen now
I run blugon --once
only and see no resets with xfce4-screensaver (when it triggers itself, I don't have that -demo
one though), on ArchLinux. I've also tried dpms-ing manually even, and still no resets, the color temperature is kept.
sleep 1
xset dpms force suspend
sleep 1
xset dpms force off
sleep 1
xset dpms force standby
setterm --blank force
Now I notice that I've no brightness reduction setting(it's set to Never) so maybe this is why?
nope that's not it, I've set it to 10 seconds and it doesn't change color temp. (only the brightness)
So I've no idea why I've no problems but other people do.
oh wait, my bad xfce4-screensaver
is not xscreensaver
. I've no idea why I equated the two.
Is the Install Colormap
from Advanced
tab inside xscreensaver-demo
selected and selectable? it's unselectable/disabled for me. I think this is why I can't reproduce the reset(s) with these steps, thus the color temperature is kept.
installColormap (class Boolean)
On PseudoColor (8-bit) displays, install a private colormap
while the screensaver is active, so that the graphics hacks can
get as many colors as possible. This is the default. (This
only applies when the screen's default visual is being used,
since non-default visuals get their own colormaps automati‐
cally.) This can also be overridden on a per-hack basis: see
the discussion of the default-n name in the section about the
programs resource.
This does nothing if you have a TrueColor (16-bit or deeper)
display. (Which, in this century, you do.)
@howaboutsenergy Good one. It is enabled and unselectable for me. I will look into a way to disable it and see if that solves the issue.
@howaboutsenergy Good one. It is enabled and unselectable for me. I will look into a way to disable it and see if that solves the issue.
Ah, I'm afraid it's always unselectable if you have 16+bit colors and thus not in effect :(
This does nothing if you have a TrueColor (16-bit or deeper)
display. (Which, in this century, you do.)
It's probably not the cause, sadly. But you can change it in ~/.xscreensaver
installColormap: True
, not sure how to restart xscreensaver afterwards though, except from xscreensaver-demo
my version:
$ xscreensaver -v
xscreensaver 5.43
EDIT: I don't want to post a new comment, just want to note that for me disabling/enabling Fade to Black
has no effect, but glad it fixed it for damscal below. (just to be clear, I'm unable to experience any issues with xscreensaver, from what I've tried, the color temperature is kept and not reset no matter what I do - so I've no issues)
I've pinpointed the issue. It is caused by the Fade to Black advanced option of xscreensaver. Disabling it solves the problem. I'm closing the issue. Thanks for the support!