Bug 58033 - Problems with dual-head and VMware
Summary: Problems with dual-head and VMware
Status: RESOLVED DUPLICATE of bug 51504
Alias: None
Product: kscreensaver
Classification: Miscellaneous
Component: screensavers (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kscreensaver bugs tracking
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-02 21:49 UTC by Jeff Riley
Modified: 2010-10-23 23:57 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Riley 2003-05-02 21:49:56 UTC
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.
Comment 1 Chris Howells 2003-05-02 21:58:35 UTC
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'?

Comment 2 Jeff Riley 2003-05-02 23:38:20 UTC
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.

Comment 3 Chris Howells 2003-05-03 00:59:42 UTC
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-----

Comment 4 Jeff Riley 2003-05-05 17:22:50 UTC
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

Comment 5 Chris Howells 2003-05-05 20:31:33 UTC
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.

Comment 6 Jeff Riley 2003-05-05 21:20:28 UTC
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.

Comment 7 Chris Howells 2003-05-06 12:25:37 UTC
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.
Comment 8 Jeff Riley 2003-05-06 17:30:09 UTC
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.

Comment 9 John Schmitt 2005-01-14 02:23:33 UTC
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
Comment 10 John Schmitt 2005-01-14 02:25:25 UTC
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.
Comment 11 George Goldberg 2008-02-18 03:48:16 UTC
Is this bug still present in a recent KDE version, such as 3.5.9 or 4.0.1?
Comment 12 Oswald Buddenhagen 2010-10-23 23:57:47 UTC

*** This bug has been marked as a duplicate of bug 51504 ***