Created attachment 20196 [details] xorg.log I have noticed this behaviour and thought gnome and debian are to blame, but second guessing led me to try the history of the driver, especially so, because during the switch I see monitor messaging me about switching off. The case is that I try to switch to other user in gnome and it always returns me to the current user's login window. One commit earlier, I could get the plain login screen for the other user but this one fails to switch to other terminal, I guess. The Xorg log is attached.
Aljaž, I'm not sure what you are talking about, as I'm not familiar how these things are done under gnome. I'm not sure what you mean by 'current/other user's login screen'. For me a login screen (I assume you are referring to gdm) is for all users. You can select a user and enter a password.
Ok, a little description. Gnome has the option of having concurrent logged in user, each using different VT above 7. That is done using either fast-switch-user applet or when the session is locked in gnome and you want to continue with the session (unlock it), then you can either return to your own session or choose the option "Switch" whereby you can change the user and then log-in. It is a similar service as under Windows XP (there also exists this fast-user-switch thing). As I am a heavy user of this functionality (I have multiple users logged in the same machine all the time) I notice the anomalies that most of the users probably don't. There was already a bug here regarding blackouts that was successfully solved (see bug #13853) and here happened again using concurrent users. What I deducted from what happens during the user switch is, that the monitor between the command and a new log-in window returns a message that it is going to sleep. That is something that didn't happen before when switching users. So I deduct that when a user says "switch user", the terminal won't switch and stays on the same VT and because this behaviour happens between this and previous commit, there has to be this code that does the difference.
OK, so a new Xserver is started for each user, I assume. The second server needs to be started with a different display. So please check if a file /var/log/Xorg.1.log exists. If it does, please remove it, perform the test again and after you have returned to the original server please attach it here. Thanks!
Created attachment 20215 [details] the failed session
I see it's DRI that fails...
Created attachment 20216 [details] the working session This is the commit that works, although I see DRI failed here, too. But anyhow, the session still works.
Fixed. Check commit: 53dd35cb766138c879c926a8374380174e876d35 Thanks for your input!
Created attachment 20238 [details] xorg log of the second user after the fix Unfortunatelly it may solve one problem but creates another. Now, the screen goes to sleep when second user logs in and the log produces was 103MB big! In the attachment I erased the repeating lines and left only three of them but can still upload the zipped version if you need it (it's about 47KB).
see comment under the new attachment
Argh! OK, thanks for the follow up! Should be fixed with commit: 4d65e4c6d96c725dafb5fa8a6fc5a252fee4c260 now :)
Created attachment 20337 [details] xorg log of the second user after the 2nd fix Now, the login succeeds but DRI is not enabled. Then, if I log off the second user, it goes ok, but if I switch from the second user back to the first, X freezes and I have to restart it via ssh. Attached is the Xorg log of the second user when trying to switch back to some other user. Switching back doesn't switch the terminal but stays on the second user, the windows are frozen, the keyboard does not respond (not even num-lock). If it is not the same stuff from the bug, tell me, for now I'll reopen this one, again.
See the comment of the previous attachment
OK, fixed that one, too. Commit: c2dfeafe7bcf330a2688f6715840188cf37a312b
Now it seems to work - the switching. But I am still curious, why does it not start DRI?: (II) [drm] DRM interface version 1.0 (EE) [drm] Could not set DRM device bus ID. (EE) RADEONHD(0): [dri] DRIScreenInit failed. Disabling DRI. (II) RADEONHD(0): Using MMIO Command Submission for acceleration. Anyway, thanx for the fix, but until DRM starts on the other user as well, I will have to either switch off DRI or switch to XAA because it's not possible to work under DRI/EXA combination (slow drawing & listing pages, etc).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.