lubuntu 19.04/19.10 xscreensaver runs on single display, other display continues normally

Bug #1814490 reported by Chris Guiver on 2019-02-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lxqt-session (Ubuntu)
xscreensaver (Ubuntu)

Bug Description

Please note: this only occurs on vertical alignment of displays (one above the other), and if top/bottom is swapped, the issue disappears...

Lubuntu 19.04 [x86_64] installed system (upgraded from 18.04 85 days ago), then 19.10 & 20.04

See comment #21 for how to re-create, OR have issue vanish using "Monitor Settings" & slight movement of monitors.

1: package suggestion by krytarik on #lubuntu-devel
2: possibly duplicate; & my reason why no (but linked for sure!)
3: occurs on QA-test of 19.04 daily

1:--- added re: package
As for package - xscreensaver may not be culprit.
It works perfectly on 18.04 Lubuntu (see comment #3 & #4 which tested prior & current package), and if I login via XFCE (Xubuntu) on same box (my install has both; comment #1). I tested killing lxqt-powermanagement which made no difference (comment #5) where it was suggested

<krytarik> Okay, then I'd say just stick lxqt-session to the bug report too and see how it proceeds. :P
2: --- possible duplicate?
I just discovered
which was for a 19.04 x86 QA-test on a laptop. I'm not marking it a duplicate as this system was installed 85+ days ago & yet I only discovered this issue now! If it were a straight duplicate I'd hope I'd have noticed it before now & seen connection with that prior bug.. On that other bug I noted I hadn't experienced it on any installed system, where now I have...
3:--- qa-test using daily image
I booted today's daily image on different box which has two displays; at first it was good (displays next to each other horizontally). I adjusted position so they were vertically placed (like they are for that box, and this reporting box the bug-report relates to). I could re-create bug by using 'monitor settings' to a vertical placement & letting screensaver run.
--- (end of addendum material)

When the screensaver takes effect, both displays go dim & go black for maybe a second then one shows screensaver, the other returns to normal display.

If i have windows (hexchat, htop/glances running) on the non-screensaver displaying window, those contents continue to receive updates allowing me to see new incoming messages in hexchat, or view the process info in htop/glances on a qterminal window.

I logged out & tried same in XFCE and it blacked both screens the same, but then showed xscreensaver images on each display (not the same image, each with its own 'image'). My system has lubuntu-desktop & xubuntu-desktop intalled. I returned to Lubuntu & re-tested and it was the same (one display showing screensaver, one resuming active windows)

To replicate:

- login to Lubuntu 19.04 (on system with two displays)
- have windows open on both displays, eg. htop so you can view detail change
- change screensaver prefers to blank after 1 min, then wait

as screensaver takes effect, both will dim, then one will display screensaver, other will return to displaying the window it was before with information (htop etc) updating as if unlocked.

i tried `ubuntu-bug xscreensaver` & it ran apport, then returned to $ prompt without browser to enter this window. this is my main desktop; x86_64 or dell [optiplex] 960 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350) on that rare occasion I use it for qa-testing. this though was my installed normal system (so likely heavily modified)

guiverc@d960-ubu2:~$ apt-cache policy xscreensaver
  Installed: 5.42+dfsg1-1ubuntu1
  Candidate: 5.42+dfsg1-1ubuntu1
  Version table:
 *** 5.42+dfsg1-1ubuntu1 500
        500 disco/universe amd64 Packages
        100 /var/lib/dpkg/status
guiverc@d960-ubu2:~$ uptime
 14:36:44 up 2:23, 1 user, load average: 0.71, 0.76, 0.81
(the system was updated fully & has been restarted after updates)

2019-04-11 - This is not a Lubuntu only issue.

I recently installed opensuse tumbleweed over a sick leap install on my hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600) box - and it exhibits the identical behavior when using LXQt.

Upstream filing :

Chris Guiver (guiverc) wrote :

on this box I normally don't have LOCKED SCREEN enabled, but I get the same result if that box is ticked or not. I tried changing screensaver & it made no difference (my default was random anyway), and the issue only occurs in Lubuntu (not Xubuntu) so it's likely a different package or config at fault so sorry.

Chris Guiver (guiverc) wrote :

in #lubuntu-devel Krytarik suggested I try an older version

<krytarik> guiverc: From a quick web search and given the behavior, it still seems likely that xscreensaver is at fault there though. Could downgrade the packages you've got manually to the previous version here and test if it's the same with that too:

I installed that version

guiverc@d960-ubu2:~$ apt-cache policy xscreensaver
  Installed: 5.36-1ubuntu1
  Candidate: 5.42+dfsg1-1ubuntu1
  Version table:
     5.42+dfsg1-1ubuntu1 500
        500 disco/universe amd64 Packages
 *** 5.36-1ubuntu1 500
        500 zesty/universe amd64 Packages
        100 /var/lib/dpkg/status

logged out & re-tried, still same effect (I can view one screen which updates its windows [htop] and screensaver runs on other).

I then rebooted & retried & got same result -- screens dim for a second (a very nice effect) then one display resumes it's display of htop/hexchat etc & other shows xscreensaver...

Chris Guiver (guiverc) wrote :

in #lubuntu-devel

<krytarik> guiverc: Okay. Try and reproduce this on a Lubuntu 18.04 Live medium to perhaps exclude LXQt being a factor.
<guiverc> krytarik, does arch matter? (my box is x86_64, have found lubuntu 18.04 i686 thumb-drive) will that do?
<guiverc> or should i keep looking (or write a x86_64)?
<krytarik> No, can't imagine it does.

I booted lubuntu 18.04.1 (x86 or i686) on this box
I added 'zesty' & 'zesty-proposed' repos to sources; sudo apt update
`apt-cache policy xscreensaver` showed both bionic & zesty provided same 5.36-1ubuntu1 version

sudo apt install xscreensaver
had it run (1 min no activity)

both screens dimmed, and then screensaver ran on both displays (different colors & patterns on each). stopped it, waited again & same result (both screens hidden by screensaver with different patterns & colors used on each monitor's screensaver image). this is expected behavior.

Chris Guiver (guiverc) wrote :

I rebooted x86 lubuntu 18.04.1 (no xscreensaver package is installed by default)

added 'disco' universe (& main) repo's & installed xscreensaver 5.42+dfsg1-1ubuntu1
it pulled in a few requirements (updated libc6 & some other stuff)
set idle time to 1 min & let it run..; made sure it ran an installed screensaver

screensaver worked perfectly; both screens, different patterns & different colors on each display, unable to see windows that were on displays before screensaver took effect

logged out & logged back in. ensured screensaver was good (ie. 1 min, htop on both screens so I have a window to see if it fails to run etc), then let it take effect
again it worked perfectly, different pattern & colors on each display.

Chris Guiver (guiverc) wrote :

from #lubuntu-devel

<krytarik> guiverc: Okay, thanks. Then it seems like the correct package to file the bug report against is somewhere in the LXQt space.

<krytarik> guiverc: Try and "killall lxqt-powermanagement" and see if it's still the same then?
<krytarik> Otherwise, only lxqt-session comes to mind as a possible culprit.

I `killall -9 /usr/bin/lxqt-powermanagement` until I got a message that it'd 'crashed' too many times and wouldn't restart until next login (well done & kudos to lxqt-powermanagement devs)

the effect was no different. On my lubuntu 19.04 installed system (no reboots since yesterday) screens dim, then one screen has screensaver & other is restored to qterm+hexchat which update normally fully visible.

<krytarik> Okay, then I'd say just stick lxqt-session to the bug report too and see how it proceeds. :P

Chris Guiver (guiverc) on 2019-02-05
description: updated
Chris Guiver (guiverc) wrote :

I just booted a 19.04 daily image used in my last Lubuntu x86_64 QA-test [booted on hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)]. The daily.ISO was downloaded 29-Jan with ISO dated 28-Jan, and xscreensaver had no issues with two screens (both showed different color & different images & no htop's visible). I've re-powered up my file server so updating my daily & plan to re-test with todays.

Chris Guiver (guiverc) wrote :

latest daily image (lubuntu 19.04 daily image), and at first no problems (just re-did test in comment #6)

i then changed my displays to vertical (one above the other as I really have them) and waited...

bingo - problem, screen dims then top display has screensaver & bottom returned to prior image (monitor settings & qterminal on display both readable). alas i've overwritten the 29th-Jan USB with today's so cannot reboot & modify screen position to see if #6 did the same (can't write new one as .iso was zsync'd to today's)

Chris Guiver (guiverc) on 2019-02-05
description: updated
description: updated
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Chris Guiver (guiverc) wrote :

from #lubuntu-devel

<krytarik> guiverc: As per your comment 7 on LP bug 1814490, did you test the other desktop environments also with the vertical positioning of your displays, or could you do so now?

<guiverc> krytarik, FYI: Kubuntu 19.04 daily of jan 17 - no issues (as booted (horizontal arrangement) & when screens made vertical) -- it was already on thumb-drive

<guiverc> krytarik, FYI: Xubuntu 19.04 daily (latest) & no issues with xscreensaver (as booted (horizontal) & vertical arrangement)

<krytarik> guiverc: Okay. And if you test it on Lubuntu 18.04 too, that would be great.
<lubot> <HMollerCl> I want to change the default icons for papirus (not dark) which branch should I arc with?

<guiverc> krytarik, i did lubuntu 18.04.1 x86 earlier (lp comment #3 & #4 which was unclear about screen orientation shifts), wrote 18.04.1 x86_64 & redid tests with default 5.36-1ubuntu1 and all good, loaded 5.42+dfsg1-1ubuntu1 & restarted xscreensaver & good (vertical orientation of displays)

<krytarik> guiverc: Okay. Wanna go add lxqt-session as another affected package to the bug report then? Otherwise, it'll probably never get looked at, as the numerous other xscreensaver bug reports.

Chris Guiver (guiverc) wrote :

QA-Test 2019-02-16 on hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)

// 19.04 daily x86_64
// following are selected portions copied/pasted from QA-test report.

change monitor-settings to match my [weird] vertical setup (one monitor above other)
my left open pcmanfm-qt & firefox windows got pushed [mostly] off screen, but i was able to drag back correctly...
screensaver changed to 1 min, it runs only on top display (not bottom which was right before arrangement altered), which continues to display counter of vlc playing music... ie. not hidden -

i adjusted monitor-settings back to left-right configuraton (as it was when booted) & re-did some of the above bug-report tests, the screensaver did not correct itself, with 2nd monitor unhidden & vlc counter continued counting up as played mp3, & muted firefox kept streaming abc news 24 (au news).. both monitors are dimming before screensaver draws, then bottom/right monitor resumed to display of firefox streaming news & part of vlc visible showing time-position of mp3... i've restarted screensaver-daemon & waiting... restart made no difference. logging out & back in.. (monitors left-right arrangement as like when booted, but changed a 2(+) times... this time both screens are covered by screensaver!!!

Chris Guiver (guiverc) wrote :

2019-02-17 19:30 QA-Test Lubuntu 19.04 daily (live) x86_64

// this [screensaver] issue occurs on my installed system too (Lubuntu only, not when logged in via XFCE/Xubuntu; I rarely use GNOME/Ubuntu..)
// the following is selected bits pasted from my QA-TEST comment
// minor note: vlc is mentioned in a drag - it was playing background music

dell [optiplex] 960 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

Now change orientation of displays, pref->lxqtsett->monitor.settings_set.position
DVI-1 is setup directly BELOW DVI-0 (my real setup has slight horizontal diff, but that creates more issues I now ignore for qa-testing; vertical arrangement is simpler to replicate)
drag VLC so it's full onscreen (only left part was visible - ignoring this)..

This is my USED system, .. Yes my system is hugely modified (xubuntu & ubuntu are installed, lots of apps, lots of changes but mostly to xfce)...

went and changed screensaver to 1 min, m6502 selected & wait... screen dims then screensaver operates on dvi0 but dvi1 returns to show what is was showing (unhidden).. I didn't have a changing window on that display so will move vlc to that one so I can verify count still changes...
opened qterminal (ctrl+alt+T) and maximized, fine on dvi0, but fullwidth & no only top panel (no black area visible on maximized (
yep htop still displays with count & vlc slider moving as music progresses even though screen has dimmed & m6502 screen saver is running on dvi0

i changed display orientation back to what it booted as (DVI0 on left, DVI1 just to right) and all maximize, minimize, menu showing & usable, etc issues were solved... it relates only to monitor.position and most people will have left-right I bet. (screensaver bug was unaltered! it still shows htop running dvi0 & htop running perfectly visible dvi1 but I've covered this in prior QA-test report. I restarted screensaver deamon (even changed from m6502 to another) & dvi0 is hidden, dvi1 perfectly visible.

logging out. check screensaver says 1 min, open two terms & have htop visible on both (one per display) & wait... -- nah still effecting screen. Alas I didn't test this before altering display.position...

Chris Guiver (guiverc) wrote :

QA-test Lubuntu 19.04 on hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)

// following from qa-test comments

adjusted monitors to vertical as my displays are (prefs->lxqt.settings->monitor.settings) - monitor which was on right is now below

opened two terms running htop; one on each display & adjusting screensaver to 1 min activate & single-saver (an installed one) & preview only hides a single display ! further as I typed this the minute passed & bottom screen returns after dim with screensaver only visible on top display (htop is updating on lower display)

Chris Guiver (guiverc) wrote :

adding a screenshot (delay of 70 secs on screenshot, 1 min till bsod scrensaver shows)

BSOD screensaver can be seen on top display; bottom display shows htop/term/screensaver.prefs which shouldn't be visible (htop updates constantly)...

(My displays are not vertically aligned which accounts for background visible in section top-left & bottom-right)

Chris Guiver (guiverc) on 2019-04-11
description: updated
Chris Guiver (guiverc) on 2019-04-11
description: updated
Chris Guiver (guiverc) on 2019-04-11
description: updated
Chris Guiver (guiverc) wrote :
Chris Guiver (guiverc) wrote :

I have marked as a duplicate of this one.

This issue still occurs on my primary machine (19.10), and occurs regularly if I test for it with 'live' with QA-testing (19.10).

Upstream have indicated an opinion that it'll be fixed when other issues are fixed (
"Tsujan: I have a feeling that this, #1704 and #1703 have the same cause." though as I noted later in #1705, this issue remains on my primary box where 1704 & 1703 no longer annoy me.

Chris Guiver (guiverc) wrote :

this issue occurs on installed systems (my primary d960 which used to be 19.04, now 19.10), plus live systems (19.04 & 19.10, not when initially booted; but when screens adjusted to be one above the other - but issue only occurs one way; if swapped top-bottom both screens have xscreensaver active on them). Adding disco & eaon tag is reason for this comment; still present on today's daily reason I looked.

tags: added: disco eoan
Chris Guiver (guiverc) on 2019-09-27
description: updated
summary: - lubuntu 19.04 xscreensaver runs on single display, other display
+ lubuntu 19.04/19.10 xscreensaver runs on single display, other display
continues normally
Chris Guiver (guiverc) wrote :

hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
purpose of this test is to start looking for old bugs & confirm focal impacted; these bugs are old & upstream issues and will impact very few end-users (impact me thus why chased)
boot up; adjust displays to match my setup (default-right display is below other display)
opened screensaver settings; clicked preview & only top display is hidden -

tags: added: focal
Chris Guiver (guiverc) wrote :

upstream message left on
Another user has commented upstream having this issue with 3 screens

Chris Guiver (guiverc) wrote :

Lubuntu 20.04 QA-Test on
dell [optiplex] 960 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

This issue was re-created today. Please refer to comments on as to what I did (started >60 mins ago)

Of primary note was once issue was created.. (ie. Monitor.Settings to change screen position and panel on each display)

Running `xfwm4 --replace` would have NO EFFECT on issue occurring. It still occurred.

Chris Guiver (guiverc) wrote :

I just noticed screensaver kicked in on both my displays on my primary (d960) 20.04 box. This maybe the first time I've seen this on this box since Lubuntu went to LXQt (whilst using LXQt/Lubuntu anyway).

The only change made relates to play where the “Keep Monitors attached” checkbox was ticked a number of times for testing...

Upstream have mentioned something causes a value to be set (maybe issue was an uninitialized flag/value; but a number of issues were ~linked) which fixes the issue; if just clicking this 'checkbox' on & off maybe is a workaround. Maybe it's just co-incidence, but I can't think of anything else today that would change it.

Chris Guiver (guiverc) wrote :

On d960 box..

To have screensaver hide only 'top' of my two displays (positioned one above the other with top slightly right)

- tick "Keep monitors attached"
- move a monitor so they snap together
- in screensaver click 'preview' or wait until it kicks in

The screensaver will only show on top display, bottom will not be hidden.

To have screensaver work on both displays

- untick "Keep monitors attached"
- position monitors so a tiny gap exists between them
- in screensaver click 'preview' or wait until it kicks in

The screensaver will cover both displays.

I think the "Keep Monitors attached" causes a pixel (or two?) to overlap (when dropped & they 'snap' together to 'be attached'; upstream have claimed to have fixed this - but I got confused trying to test their 'patch'; so whilst Dan may have included the patch downstream in Lubuntu maybe it didn't work as well as hoped (and I didn't report upstream)...

description: updated
Chris Guiver (guiverc) wrote :

daily 20.04 qa-test on hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)

I suspect the issue in this bug relates to that bug (top-half of wallpaper appears on my bottom-monitor, my top-monitor being dark except for bottom pixel or two which is always the color matching the top of the wallpaper shown on screen below..)

I can fiddle with Monitor.Settings and make this screensaver work on both display, OR work on single display only using Keep.monitors.attached and position of displays - this applies to both bugs. However I don't get both bugs occurring at the same time, nor different times. I believe they are linked, but cannot work out the pattern (or not yet anyway).

The two bugs do NOT always occur, I often get one occurring and not the other.

-- following is from comment 3 of

I suspect from play this issue relates to, and an issue I've been wanting to raise upstream for a few weeks (but am unsure how to word..). Keep.monitors.attached??

What was obvious though - there was a bright blue line bottom of my-top monitor, being the top of the wallpaper (1910-boat-on-beach.png) that I suspect relates to issue, it shouldn't be there I believe (ie. slight overlap) occurs when Keep.monitors.attached is checked.. that seems to cause 1814490 & this to be mostly predictable..

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.