From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314 Description of problem: When locking the screen, either through time-delayed screen saver activation or using the "Lock Screen" command in the KDE menu, the display "cycles" (clicks on and off, as if changing resolution), and goes to the graphical login screen. The selected screensaver doesn't come up, it just dumps out to this screen. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Login to KDE (I am using a graphical login after bootup) 2. "Lock Screen" or wait for screensaver to kick in Actual Results: The display "cycles" (clicks on and off, as if changing resolution), and goes to the graphical login screen. If I log in here as the same user, it attempts to start up another KDE session. It loads the desktop, but then most KDE programs (Kmail, Konqueror) don't work because they only like one instance of themselves. Non-KDE programs such as Mozilla and Gaim open up additional copies of themselves. If I do not log in at this screen, and instead switch to a console (ctrl-alt-F1), and then from there go back to X (alt-F7), the screensaver comes up as expected. Expected Results: The screensaver or blank screen should have come up. Additional info: This is a fresh install of Skipjack, with graphical login enabled. I haven't tried it with text-mode login yet, or with Gnome; I'll try that soon.
Can't reproduce this with 3.0.0-1, assuming it's fixed.
I'm seeing this with a fresh skipjack install + up2date -u jmm@jmm:/home/jmm> rpm -qf $(which kdm) kdebase-3.0.0-0.cvs20020321.1 It's interesting - the lock screen actually isn't breaking the existing virtual console. Basically what happens is: - kdm starts on vt 7 as per normal runlevel 5 - user logs in - user clicks lock screen (or any other method for getting to lock screen) *** here's the critical part *** - the kde / X on vt 7 *DOES LOCK THE SCREEN* just fine - what happens is that a new kdm "instance" starts on vt 8 and the console is switched over to vt 8. Specifically, an instance of "kdm_greet" is started. - If the user switches back over to vt 7 (ctl+alt+f7) and unlocks the screen then the kdm_greet on vt8 goes away this effect does cascade as well, meaning if one user logs in to kdm on vt7, locks the screen, another user then logs in to the kdm_greet kdm front on vt8 and locks their screen, a kdm_greet happens on vt9 with vt7 and vt8 both locked. Once vt8 unlocks, the kdm_greet on vt9 goes away, then logging out there and unlocking vt7 has the kdm_greet on vt8 go away. *** note: random babbling coming up *** I get the feeling at this point that it's a keyboard/mouse device access kind of things going on - the process of locking the screen is doing something to forcefully grab those devices and kdm (still running) picks that up as a problem and starts the new kdm_greet. Now, *potentially*, this is a very-much-intended feature so (say in a university computer lab) someone can't make a machine's console worthless with a locked session - a new kdm_greet starts and whoever walked away (just locking the screen) is back. I could definitely see this being a very useful feature. It'd be nice if it were confirurable if it's intentional, and even better if it defaulted to no new kdm_greet so univ. computer labs could just switch the config option and get this nice behavior for them while leaving it as "lock and don't start a new kdm_greet" for the rest of us.
Created attachment 52130 [details] specific processes created when the screen gets locked
hopefully the processes getting spawned will make the code path easier to find. As another data point, if this sequence happens: - normal boot, user logs into vt7, locks screen - kdm_greet starts on vt8, diff (dunno if it can be the same) user logs in to vt8 - switch to vt7, user unlocks then at that point (vt8 has a running kde session), the vt7 user locking the screen *DOES NOT* start a new kdm_greet and switch over - it just locks. This is feeling more and more like a very intentional feature that would be great to have but should be turned off by default :)
yup, it's intentional, and that's nice, but it should really be configurable. $XDM_MANAGED is set for the fifo's that clients can talk to the running kdm over. this is done in kdm's backend/client.c http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdm/backend/client.c (line 798 in ver 2.23) kdesktop_lock parses this variable and picks the first entry (comma-separated) as the fifo to send strings to. When it locks, it'll send "lock\n" (if not a child screen saver) and sends "unlock\n" on unlock. http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdesktop/lock/lockprocess.cc (lines 539, 565 of version 1.4) when the display manager processes the lock message, he does exactly what I guess - if all displays are locked, start a new greeter. http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdm/backend/dm.c (lines 770-773 of version 1.36) 1) If you really can't reproduce this behavior to start with, that would seem to indicate a bug that you're seeing since it seems obviously intended 2) as I said before, this is nice to have in many situations but should really be configurable and default to not starting the reserve display (spawning a kdm_greet). Looks like it'd be pretty simple to add that code.
anyone else seeing one of the comments as having an (apparently) very long line? all I see from here is that the width of this page is now about 4x of what it needs to be. I think there's another konqueror textarea bug to be entered :)
(OT) I'm getting the long line displaying in Konqueror, but not Mozilla (the page as rendered in Moz has normal width). I can't see very obviously where it is showing up, but it's only the comment table that is wide.
the less-than-optimal-but-fixes-the-bug patch --- kdebase/kdm/backend/dm.c.orig Wed Apr 3 20:52:34 2002 +++ kdebase/kdm/backend/dm.c Wed Apr 3 20:52:54 2002 @@ -772,2 +771,0 @@ - if (AllLocalDisplaysLocked (0)) - StartReserveDisplay (0);
for me, the bug disappeared since kdebase-3.0.0-2
I can not reproduce this problem with kdebase 3.0.0-2 (haven't tried older ones)
Make sure you use the current kdm config files (upgrading may have kept the old files intact and put the new ones in as .rpmnew files, maybe that's why you've still seen this after I've closed the report).
I'm on the "3.0.0-2 works for me" bandwagen as well.
confirmed fixed in 3.0.0-3