jumper149/blugon

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?
Screenshot_2019-10-04_14-38-22

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!