Version: (using KDE KDE 3.1.1) Installed from: RedHat RPMs OS: Linux I have no idea if VMware has anything to do with this or not. Here is the basic stream of events... 1. I login and let the screensaver activate. It comes up on both screens (I'm running dual-head mode) as it should. Then I hit a key or move the mouse and they both wake up as expected. 2. I let it timeout again, and only the 2nd screen starts up the screensaver while the 1st remains active. I can move the mouse and type in the 1st screen and the screensave will stay on in the 2nd screen. If I move the mouse in to the other screen it will wake up. 3. At this point it will no longer fire up the screensaver after the timeout period, I've left it overnight. The only way to get it to come on is by hitting the Lock button on the taskbar on the 2nd screen. The Lock button on the 1st screen does nothing at all. When I hit the Lock button on the second screen, the screensaver fires up on both screens, consistently, and any movement will bring up the password box. I've got two relatively expensive monitors and I keep forgetting to manually turn on the screen saver. Here's the thing, if I log out and log back in again, this procedure starts over at step 1 above.
Subject: Re: New: Predictable but wrong screensaver behavior in dual-head mode and VMware running Hi, On Friday 02 May 2003 20:49, Jeff Riley wrote: > 1. I login and let the screensaver activate. It comes up on both screens > (I'm running dual-head mode) as it should. Then I hit a key or move the > mouse and they both wake up as expected. Presumably this is with Xinerama? > 2. I let it timeout again, and only the 2nd screen starts up the > screensaver while the 1st remains active. I can move the mouse and type in > the 1st screen and the screensave will stay on in the 2nd screen. If I > move the mouse in to the other screen it will wake up. Have you started VMware by this time? > 3. At this point it will no longer fire up the screensaver after the > timeout period, I've left it overnight. The only way to get it to come on > is by hitting the Lock button on the taskbar on the 2nd screen. The Lock > button on the 1st screen does nothing at all. When I hit the Lock button > on the second screen, the screensaver fires up on both screens, > consistently, and any movement will bring up the password box. Assuming that you have started up VMware by this stage, it sounds like a bug that was recently fixed (will be in KDE 3.1.2) where kdesktop_lock (the program responsible for launching screenavers) would just run in the background, doing nothing if it couldn't grab they keyboard because VMware was running. See http://bugs.kde.org/show_bug.cgi?id=46515 for info on that bug. Can you give me the output of 'ps aux | grep kdesktop_lock'?
Subject: RE: Predictable but wrong screensaver behavior in dua l-head mode and VMware running > Presumably this is with Xinerama? As far as I know... I had to manually setup the Xconfig86 file in order to get the two screens to work properly. I've heard the Xinerama term used before, but do not know exactly what it is or if I'm using it to accomplish the dual-head mode. I do have it running in a true dual mode and not the extra-wide single screen mode. I'm sure that didn't answer your question... let me know if you need more info. > Have you started VMware by this time? Yes. I've done some experimenting and if definitely is if the screensaver attempts to kick in while VMware has the mouse and keyboard grabbed, the screen with VMware on it stays active while the other screen fires up the screensaver. This is obviously the problem. After this point, it won't fire up on either screen. > Assuming that you have started up VMware by this stage, it sounds like a bug > that was recently fixed (will be in KDE 3.1.2) where kdesktop_lock (the > program responsible for launching screenavers) would just run in the > background, doing nothing if it couldn't grab they keyboard because VMware > was running. This is probably it, what is the fix in 3.1.2? Is it possible to get just that patch? Or when is 3.1.2 going to be released? > Can you give me the output of 'ps aux | grep kdesktop_lock'? I never see this running. Before or after VMware. I've tried checking for it at several different times and I've never found it yet.
Subject: Re: Predictable but wrong screensaver behavior in dual-head mode and VMware running Hi, On Friday 02 May 2003 22:38, Jeff Riley wrote: > As far as I know... I had to manually setup the Xconfig86 file in order to > get the two screens to work properly. I've heard the Xinerama term used > before, but do not know exactly what it is or if I'm using it to accomplish > the dual-head mode. I do have it running in a true dual mode and not the > extra-wide single screen mode. I'm sure that didn't answer your > question... let me know if you need more info. Apparently the wide single screen mode is accomplished using Xinerama, so you may not be using it. > Yes. I've done some experimenting and if definitely is if the screensaver > attempts to kick in while VMware has the mouse and keyboard grabbed, the > screen with VMware on it stays active while the other screen fires up the > screensaver. This is obviously the problem. After this point, it won't > fire up on either screen. OK. Unfortunately it's technically not possible to make VMware drop the grab, so the best we can do is not start the screensaver. > This is probably it, what is the fix in 3.1.2? Is it possible to get just > that patch? Or when is 3.1.2 going to be released? KDE 3.1.2 should be released in about 10 days or so. Patches are: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdesktop/lock/lockprocess.cc.diff?r1=1.15&r2=1.16 and http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdesktop/lock/lockprocess.cc.diff?r1=1.16&r2=1.17 > > Can you give me the output of 'ps aux | grep kdesktop_lock'? > > I never see this running. Before or after VMware. I've tried checking for > it at several different times and I've never found it yet. kdesktop_lock is responsible for running the screensaver, so it must be running while the screensaver is on. If it isn't running when the screensaver has stopped, it must be a different problem I guess. It was just the fact that a kdesktop_lock was already running in the background (because it had failed to get the grab) preventing another kdesktop_lock from being launched and in turn launching the screensaver. If you kill kdesktop with, could you please then run kdesktop in a terminal to get the debugging output (I assume you're not running a release build...) - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP ID: 33795A2C KDE: http://www.koffice.org, http://printing.kde.org, http://usability.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE+svhXF8Iu1zN5WiwRAietAKCOsdhBVMUwEJrZxwqq9haM50+zDgCgoLvp r20rrimitLxc+ggu1ReAisw= =aiyn -----END PGP SIGNATURE-----
Subject: RE: Predictable but wrong screensaver behavior in dua l-head mode and VMware running -----Original Message----- From: Chris Howells [mailto:howells@kde.org] Sent: Friday, May 02, 2003 5:00 PM To: jeff.riley@quantum.com Subject: [Bug 58033] Predictable but wrong screensaver behavior in dual-head mode and VMware running OK. Unfortunately it's technically not possible to make VMware drop the grab, so the best we can do is not start the screensaver. > This is probably it, what is the fix in 3.1.2? Is it possible to get just > that patch? Or when is 3.1.2 going to be released? KDE 3.1.2 should be released in about 10 days or so. Patches are: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdesktop/lock/lockprocess.c c.diff?r1=1.15&r2=1.16 and http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdesktop/lock/lockprocess.c c.diff?r1=1.16&r2=1.17 What exactly do these fix? I'm guess it just allows kdesktop_lock to timeout or kill itself and start a new copy? It's looking more like I just have to remeber to move the mouse out of the VMware window before I leave it. It would be cool in VMware could add a hook that kdesktop_lock could use to release the grab, however we both know how likely that is. > > Can you give me the output of 'ps aux | grep kdesktop_lock'? > > I never see this running. Before or after VMware. I've tried checking for > it at several different times and I've never found it yet. kdesktop_lock is responsible for running the screensaver, so it must be running while the screensaver is on. If it isn't running when the screensaver has stopped, it must be a different problem I guess. It was just the fact that a kdesktop_lock was already running in the background (because it had failed to get the grab) preventing another kdesktop_lock from being launched and in turn launching the screensaver. If you kill kdesktop with, could you please then run kdesktop in a terminal to get the debugging output (I assume you're not running a release build...) Actually I am running a release... this is my main work computer and I can't really live on the bleeding edge and risk losing work time. Also, I'm far from a Linux expert and am not quite sure what you were asking me to do. Jeff
Subject: Re: Predictable but wrong screensaver behavior in dual-head mode and VMware running Hi, On Monday 05 May 2003 16:22, Jeff Riley wrote: > What exactly do these fix? I'm guess it just allows kdesktop_lock to > timeout or kill itself and start a new copy? It's looking more like I just > have to remeber to move the mouse out of the VMware window before I leave There was a bug with kdesktop_lock which meant that it would just continue running, but doing nothing, if it couldn't grab the keyboard and mouse. The patches ensure that kdesktop_lock terminates if it can't grab the keyboard and mouse so that it doesn't prevent the screensaver from starting in the future. > it. It would be cool in VMware could add a hook that kdesktop_lock could > use to release the grab, however we both know how likely that is. Yes, improved screensaver support there would be nice. > Actually I am running a release... this is my main work computer and I > can't really live on the bleeding edge and risk losing work time. Also, > I'm far from a Linux expert and am not quite sure what you were asking me > to do. Basically, find out the pid number of desktop by doing ps aux | grep kdesktop: Then kill it and restart kdesktop from a konsole. See if you get any text in the terminal: ps aux chris@galadriel:~> ps aux | grep kdesktop chris 1983 0.1 2.1 119680 16892 ? S 14:32 0:10 kdeinit: kdesktop chris 1986 0.0 0.8 21576 6404 ? S 14:32 0:00 kdeinit: kio_file file /tmp/ksocket-chris/klauncherPQ1qdb.slave-socket /tmp/ksocket-chris/kdesktopQ3aKrc.slave-socket chris 17752 0.0 0.0 3540 564 pts/2 R 16:50 0:00 grep kdesktop chris@galadriel:~> kill 1983 chris@galadriel:~> kdesktop& [1] 18185 chris@galadriel:~> kdesktop: Saver Engine started, timeout: 60 Let it start the screensaver and attach the text in the terminal, if any.
Subject: RE: Predictable but wrong screensaver behavior in dua l-head mode and VMware running Ok, I've tried this and didn't get anything at all. Here's what I did get... ~> ps aux | grep kdesktop jriley 17006 0.3 0.8 318568 18164 pts/5 SL 13:14 0:00 kdesktop jriley 17007 0.4 0.9 318864 18784 pts/5 SL 13:14 0:00 kdesktop jriley 17024 0.0 0.0 3540 628 pts/5 S 13:18 0:00 grep kdesktop ~/xez6/tests/cmp> kill 17006 17007 ~> kdesktop& [1] 17027 ~> [1] Done kdesktop ~> I let it start the screensaver but it didn't add anything to the konsole. Did I miss something? -----Original Message----- From: Chris Howells [mailto:howells@kde.org] Sent: Monday, May 05, 2003 12:32 PM To: jeff.riley@quantum.com Subject: [Bug 58033] Predictable but wrong screensaver behavior in dual-head mode and VMware running Basically, find out the pid number of desktop by doing ps aux | grep kdesktop: Then kill it and restart kdesktop from a konsole. See if you get any text in the terminal: ps aux chris@galadriel:~> ps aux | grep kdesktop chris 1983 0.1 2.1 119680 16892 ? S 14:32 0:10 kdeinit: kdesktop chris 1986 0.0 0.8 21576 6404 ? S 14:32 0:00 kdeinit: kio_file file /tmp/ksocket-chris/klauncherPQ1qdb.slave-socket /tmp/ksocket-chris/kdesktopQ3aKrc.slave-socket chris 17752 0.0 0.0 3540 564 pts/2 R 16:50 0:00 grep kdesktop chris@galadriel:~> kill 1983 chris@galadriel:~> kdesktop& [1] 18185 chris@galadriel:~> kdesktop: Saver Engine started, timeout: 60 Let it start the screensaver and attach the text in the terminal, if any.
No, that's fine, thanks for the following up. Perhaps not suprpsingly, RedHat have built the packages without any debugging information. I'm currently busy with university exams for the next two weeks -- afterwards I'll try and get dual head working on my laptop and see if I can reproduce the problem. BTW, I wouldn't be overly concerned about monitor damange resulting from not using a screenaver: the general consensus these days seems to be that modern monitors aren't damaged from burn-in.
Subject: RE: Predictable but wrong screensaver behavior in dua l-head mode and VMware running I understand. It's not a huge deal now anyways since I learned from you that I don't need to logout to get it back to working again. I wrote a script that finds and kills all kdesktop processes and then fires it up again... so if it does get screwed up and can just restart it. That makes it much easier than logging out since I usually have an itricate setup of windows that is a little bit of a pain to get back. Not to mention the time to shut down and start up VMware... I look forward to hearing what you find out. Thanks for your time! -----Original Message----- From: Chris Howells [mailto:howells@kde.org] Sent: Tuesday, May 06, 2003 4:26 AM To: jeff.riley@quantum.com Subject: [Bug 58033] Predictable but wrong screensaver behavior in dual-head mode and VMware running ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=58033 ------- Additional Comments From howells@kde.org 2003-05-06 12:25 ------- No, that's fine, thanks for the following up. Perhaps not suprpsingly, RedHat have built the packages without any debugging information. I'm currently busy with university exams for the next two weeks -- afterwards I'll try and get dual head working on my laptop and see if I can reproduce the problem. BTW, I wouldn't be overly concerned about monitor damange resulting from not using a screenaver: the general consensus these days seems to be that modern monitors aren't damaged from burn-in.
The screensavers have a bug when using my Thinkpad T30 with two monitors and Xinerama on. It manifests itself specifically with the slide show and with the any OpenGL screen saver. Slide show tries to center images on on the whole desktop. What that means is half of the image is displayed on one monitor, the other half of the image on the other monitor. Since the monitors are of different size, it looks bad. All the OpenGL screen savers I tried would display well enough on the primary display, but would leave the second display completely blank. I'm running Fedora Core 3 with xorg-x11-libs-6.8.1-12.FC3.21 and xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21
I think the screen savers need a configuration for each screen/monitor. It would be nice if I could specify a screen saver for each monitor independently or I could specify that the slide show screen saver show a different image on each display.
Is this bug still present in a recent KDE version, such as 3.5.9 or 4.0.1?
*** This bug has been marked as a duplicate of bug 51504 ***