Run Xscreensaver on only one monitor

emjustem · 2022-11-03 18:45:56

In addition to my two LCD monitors, I have a CRT I want to protect from burn-in. Usually I only use it for specialized tasks, and most of the time it's just sitting there while I use the two main monitors, so I want to use XScreensaver on my CRT, but while it's running on that one I don't want it running on my other monitors, and I don't want activity on my other monitors to turn off the screensaver. I could, of course, just hit the power button on the CRT and turn it on and off manually, but that's why we invented screensavers in the first place.

I think the way to do this is configure X with a second Screen or maybe a second Display, but the tinkering I've tried has resulted in X failing to start until I revert my changes and reboot

what I tried was adding 15-crtss.conf to /etc/X11/xorg.conf.d

Section "Screen"
    Identifier "crt"
    Device "rx8600"
EndSection

Section "Monitor"
    Identifier "HDMI-A-1"
    Screen "crt"
EndSection

it might be that I'm defining a monitor which has already been defined and X sees that as a conflict, but I don't know where to find where that monitor has already been defined to comment it out and try that.

By the way, I'm running XFCE.

cfr · 2022-11-03 19:30:51

https://wiki.archlinux.org/title/Multih … te_screens

Note that I don't know how this will work with Xscreensaver specifically.

Last edited by cfr (2022-11-03 19:31:45)

seth · 2022-11-03 20:06:04

1. how about turning the crt off when you don't need it?
2. a multihead/zaphod setup as suggested in the wiki cfr linked will prevent you from moving windows from one output to another - is that desired?
3. just run a screensaver hack and use your WM to fullscreen the window on the crt output, eg.

/usr/lib/xscreensaver/glmatrix

cfr · 2022-11-03 22:52:21

seth wrote:

1. how about turning the crt off when you don't need it?

This is absolutely the right solution from every perspective. It drives me crazy that my workplace is filled with screens which are never turned off, though nobody is looking at them. Then they will be asking us if we can figure out why our building is using so much energy ....

emjustem · 2022-11-04 18:36:05

cfr wrote:

https://wiki.archlinux.org/title/Multih … te_screens
Note that I don't know how this will work with Xscreensaver specifically.

Do you know where I can read on how to set X up to work this way? This page seems to only talk about what happens after X has been set up with "separate screens", not how to set it up that way. Like I said in the OP, I tried adding a file to xorg.conf.d but I think I was doing something wrong.

seth wrote:

1. how about turning the crt off when you don't need it?
2. a multihead/zaphod setup as suggested in the wiki cfr linked will prevent you from moving windows from one output to another - is that desired?
3. just run a screensaver hack and use your WM to fullscreen the window on the crt output, eg.
/usr/lib/xscreensaver/glmatrix

1. This is what I've been doing, but as it requires manual physical activation, I often forget to do it and I'll come back the next morning and find the CRT on. Worst of both worlds! Plus I like having a cool animation.
2. It is desired but I'm willing to accept that limitation
3. I've thought about this but I still would have to open and close the hack manually and have the same problem as (1). Closing it is not a big deal as probably the hacks automatically close themselves when they receive a click or keypress, but I don't know how to tell it "Start this script automatically after X minutes of no activity in this specific region of the display".

Last edited by emjustem (2022-11-04 18:37:19)

seth · 2022-11-04 20:11:31

https://archlinux.org/packages/communit … xautolock/
https://archlinux.org/packages/community/x86_64/wmctrl/
"xprop" will tell you the class of the hack.
Moving it onto the geometry of the target outptut and setting it fullscreen there should™ work as expected w/ most WMs (but that really depends - you could however also explcitly configure its geometry w/o actually setting it fullscreen)

I often forget to do it and I'll come back the next morning and find the CRT on

DPMS is supposed to toggle the outputs off, if that doesn't work you can also bind xautolock to "xrandr --output <output name> --off"

cfr · 2022-11-04 21:12:39

I often forget to do it and I'll come back the next morning and find the CRT on

You don't want something specific to a particular monitor for this, though, right? You just need something which will turn all the monitors off. It's for the case where you're using the other monitors that you need something special, isn't it?

emjustem · 2022-11-05 16:46:40

seth wrote:

https://archlinux.org/packages/communit … xautolock/
https://archlinux.org/packages/community/x86_64/wmctrl/
"xprop" will tell you the class of the hack.
Moving it onto the geometry of the target outptut and setting it fullscreen there should™ work as expected w/ most WMs (but that really depends - you could however also explcitly configure its geometry w/o actually setting it fullscreen)
I often forget to do it and I'll come back the next morning and find the CRT on
DPMS is supposed to toggle the outputs off, if that doesn't work you can also bind xautolock to "xrandr --output <output name> --off"

Reading the manual for xautolock, So it seems like what I can do is set the -cornersize to be 5120px (large enough to cover the two LCDs but not extend onto the CRT, and give that corner a + in -corners. That way when I'm working on things in the LCD monitors, it will be "in the corner" the whole time and turn off the CRT. Then when I want to use the CRT I just have to kill the hack. This should probably work? But it's just insane enough that I want to make sure that's what you were suggesting/see if there are any better ideas.

cfr wrote:

I often forget to do it and I'll come back the next morning and find the CRT on
You don't want something specific to a particular monitor for this, though, right? You just need something which will turn all the monitors off. It's for the case where you're using the other monitors that you need something special, isn't it?

That's accurate but it IS also the case that I will be working on something on the LCDs for a couple hours and then look over and realize I've had a static image sitting on the CRT the whole time (I didn't mention it because that scenario is slightly more embarrassing than leaving it on overnight )

seth · 2022-11-05 21:09:35

I didn't consider the "embarrassing" case (your words) - a problem you might be facing w/ this is that if your CRT is top/left of the other outputs and you "xrandr … --off" it, the geometry of the other outputs will adjust to move the overall geometry to 0,0 what might lead to a race condition w/ your xautolock corner.

emjustem · 2022-11-06 17:51:13

Hm. It sounds like the "right" way to do this, which would avoid that problem and probably a few others, would be to figure out how to set up my xconf with multiple screens as in https://wiki.archlinux.org/title/Multih … te_screens

Arch Linux

#1 2022-11-03 18:45:56

Run Xscreensaver on only one monitor

#2 2022-11-03 19:30:51

Re: Run Xscreensaver on only one monitor

#3 2022-11-03 20:06:04

Re: Run Xscreensaver on only one monitor

#4 2022-11-03 22:52:21

Re: Run Xscreensaver on only one monitor

#5 2022-11-04 18:36:05

Re: Run Xscreensaver on only one monitor

#6 2022-11-04 20:11:31

Re: Run Xscreensaver on only one monitor

#7 2022-11-04 21:12:39

Re: Run Xscreensaver on only one monitor

#8 2022-11-05 16:46:40

Re: Run Xscreensaver on only one monitor

#9 2022-11-05 21:09:35

Re: Run Xscreensaver on only one monitor

#10 2022-11-06 17:51:13

Re: Run Xscreensaver on only one monitor

Board footer