When using the new qml screenlocker with a dual monitor setup, it doesn't have the same behaviour as in previous KDE versions, or as in the one monitor setup. Reproducible: Always Steps to Reproduce: 1. Lock the screen. 2. Type your password and then hit enter. - Unlocking failed 3. Click the password input, type the password and hit enter. - It works Actual Results: Unlike previous versions of the screen-locker: when starting typing in a two monitor setup, only interrupts the screensaver process on the monitor where the mouse is located, and displays the password input. However it is not focused and it needs a mouse click to be able to input your password. Expected Results: When starting typing directly the password field should be in focus and as such allow you to input the password directly.
I can reliably reproduce this with just a single monitor too.
Reproducible in today's master. I even see the following: - the machine is set to lock the screen automatically after a while - when I come back to it, press Ctrl - the focus is indicated to be in the lineedit of the second screen (why?), but typing doesn't actually type anything in it, so the screen is not unlocked after typing the password + enter. - I need to click on the lineedit to actually unlock the screen.
possible duplicate: Bug 311033
Seeing this exact bug still in 4.9.97. It's very annoying and also creates an impression of broken product (the field has a focus, typing does nothing). Imho this is also a regression as it was working correctly in 4.9 so I'm marking it as such. If anyone could provide some details/pointers on how to fix this, that'd be ace.
Happens to me as well.
Sharing a little bit investigation results: the problem is somewhere in the interaction between X11 and Qt. In the multiple monitor setup we have multiple (X) windows - one per each screen. These are QDeclarativeViews containing the QML with the password dialog. On top of all that is the lock screen. One huge X window intercepting all the mouse and keyboard events. The events are then sent to the window underneath the mouse cursor. And that seems to have problems with Qt. Qt seems to not accept any key events for non-active windows. Now it's pure chance which screen gets a "fake focus event". If that is the window underneath the mouse cursor, everything is fine, if not it doesn't work. I tried to fix it in the greeter, but without any success. I tried so far activating the window in the event filter on key press, but I rather doubt the event even gets there. Also in prepareShow() forcing an activating on the window underneath the mouse cursor had no success. Summary: doesn't work in greeter. Now I have ideas for how to get a success in the lock window. Unfortunately that will require session logouts, so I don't want to work on it right now (needs better setup with a second user for testing). The idea is to have a kind of focus-follows-mouse, so that the window underneath the cursor gets a fake focus event. Another idea I have would be to just send the events to all windows, though that's a hack.
Martin: is this the same as 311033 and 312427? Those are in single screen setups, but they describe the same behaviour. I'm not sure from your 3rd paragraph: "Now it's pure chance which screen gets a "fake focus event". If that is the window underneath the mouse cursor" whether the fake focus event can be sent only to one of the (in the 2-monitor case) two QDeclarativeViews or to a random inactive window beneath them. If the latter, I would understand that the password input could be going to a random window in the 1-monitor case, as well.
(In reply to comment #7) > Martin: is this the same as 311033 and 312427? for #311033 I don't know what "normal xscreensaver" is supposed to be. In case it is XSS, it's not a KDE thing, in case of the KScreenSaver hack: possible for #312427 it's likely to be related, but it's a different issue most likely to the multi-screen case. In the original planning it was concidered to drop the screen saver hack, so it might be that code which was needed got removed.
(In reply to comment #6) > Qt seems to not accept any key events for non-active windows. It seems at least the "unlock" button gets key press events - if I press enter, the password dialog displays an additional header "unlocking failed". BTW: If I press for example shift to get the unlock dialog, it appears only on one monitor (where the mouse is) - on the other one, the screensaver continues to run. (KDE 4.9.95 on openSUSE Factory from 2012-12-25, kdeasciiaquarium screensaver)
(In reply to comment #8) > for #312427 it's likely to be related, but it's a different issue most > likely to the multi-screen case. In the original planning it was concidered > to drop the screen saver hack, so it might be that code which was needed got > removed. Can you explain to us the difference between the password input field not getting focus, ever (bug 312427) and the issue you're reporting here? To me, they seem to be the same.
(In reply to comment #10) > (In reply to comment #8) > > for #312427 it's likely to be related, but it's a different issue most > > likely to the multi-screen case. In the original planning it was concidered > > to drop the screen saver hack, so it might be that code which was needed got > > removed. > > Can you explain to us the difference between the password input field not > getting focus, ever (bug 312427) and the issue you're reporting here? To me, > they seem to be the same. The difference is minor. Here the problem is that two windows are created at about the same time and focus is given to the window not underneath the mouse cursor. In the other one it seems like focus is not given to the window when the unlock dialog is shown. It's possible that a fix for this bug will also fix the other one, but I'm not sure about it. For the other one I will do a line by line comparison of the old unlock code with the new unlock code as I'm quite sure that code I deleted is responsible for the regression (I deleted under the assumption that the screen savers will be gone, Marco later on added them back, probably not knowing that I deleted code).
it seems like either commit 1eeb5b2f9f4a9b8edd90dea7f0538177d726126c or commit 2c4d2b2ecf17105986e3f00810448d0bcc3bb9cb also fixed this bug. I just wanted to work on it again and are no longer able to reproduce the issue. Only issue is that the text is entered sometimes on the "wrong" screen.
Isn't it possible to make the locker instances create only one password dialog on the screen marked as primary in the Settings > Display and Monitor > Size and Orientation > Primary Output section? If this is not set, display it on the screen where the mouse is located.
(In reply to comment #13) > Isn't it possible to make the locker instances create only one password > dialog on the screen marked as primary in the Settings > Display and Monitor > > Size and Orientation > Primary Output section? > > If this is not set, display it on the screen where the mouse is located. no, doesn't make sense as something has to blank the screen, so we need a lock window there anyway.
I'm sure you have more data about this issue than I do, but I fail to see how having multiple inputs makes more sense than having only one. After all, you type your password in only one place...
> I'm sure you have more data about this issue than I do, but I fail to see > how having multiple inputs makes more sense than having only one. After > all, you type your password in only one place... the problem is not "having multiple input windows", the problem is "having multiple windows". That doesn't change whether we have one or many input windows. As we cannot know on which screen the user is looking, it makes more sense to just put an unlock window on each of it (yes we thought about that ;-)
Is this fixed with commit 1eeb5b2f9f4a9b8edd90dea7f0538177d726126c One locker window seems to have the focus and when entering the password there, it hides both. (Ok, reading some comments, Martin thinks the same)
(In reply to comment #16) > As we cannot know on which screen the user is looking, it makes more sense > to just put an unlock window on each of it (yes we thought about that ;-) I think it should be safe to use the monitor the user selected as the Primary Monitor. (This would be the use-case that I, as a user, am expecting to observe) Also as an alternate option you could use a mechanism similar to the lightdm-kde-greeter's which moves the login window to the screen where the mouse pointer is, if you move the mouse.
I can confirm the screen can now be unlocked without explicit click in the password field. As of where it should be the focus, I agree that the primary screen is a safe bet, alternatively the one who has the mouse should be used.
(In reply to comment #18) > (In reply to comment #16) > > As we cannot know on which screen the user is looking, it makes more sense > > to just put an unlock window on each of it (yes we thought about that ;-) > > I think it should be safe to use the monitor the user selected as the > Primary Monitor. (This would be the use-case that I, as a user, am > expecting to observe) Note that it's possible not to have a primary monitor, so this approach would no work in such case.
There's no guarantee of an explicit primary screen, none that the user uses it as that, none that it's currently even turned on or in the same room and no reasonable way to determine where the user's looking. We can pass the focus to the window under the mouse or - maybe even better - since we hook onto the app wide event dispatcher anyway, just send the (certain) keyboard events to each greeter (ie, when you type into one, you type into all) I'm gonna check how this works tonight. Any objections, opinions or reasons that would allow me to spare that time?
> Any objections, opinions or reasons that would allow me to spare that time? mail on plasma-devel about some issues with existing architecture and QML-only (no proxy widgets in Qt 5).
this should have been fixed in master. does anybody with a multi screen setup can confirm it?
Sorry, I couldn't test the git version, but now that the 4.9.98 (Archlinux) packages were released I gave it a try and, for me, the problem doesn't manifest itself any more. When I start typing, the focus is in the dialog box from my main screen and everything works just fine. Thank you Martin.
I'm afraid the fix is not complete :-( I'm using the 4.9.98 packages in openSUSE Factory. If I try to unlock the screen without using the mouse (press any key to get the password dialog, (try to) type the password), I can't enter the password. I have to click _somewhere_ on the screen (that's the improvement, I don't need to explicitely click the password dialog anymore) before I can enter the password.
Unfortunately I have to confirm comment #25. This happens only when resuming from suspend for me though, locking it manually works properly.
@Christian Do you confirm the "only whenresume from STR" situation?
Fedora 18/KDE 4.9.98 dual screen config - here it's hit and miss. Sometimes passwd entry field gets focus sometimes it doesn't. It happens both in case of s/r, manual and idle triggred screen lock .
The only thing i can observer here is that the visual representation of the focus (on one or none of the input lines) does not necessarily match the actual focus, ie. i can _always_ type into one of the fields, but it's not necessarily correctly indicated. Is that what you observer or is typing actually only result - and how's the visual indication of the focus then?
A reboot or another Factory update (not sure which of them) improved the situation, and in most cases it works :-) There is only one situation where I can reproduce a failure: - start the screensaver (I did this using the "lock screen" shortcut) - press a key to display the password dialog (I used shift to avoid mixing up the password) - press escape to hide the password dialog - press a key to display the password dialog (using shift again) - (try to) enter the password (-> no visible result in the input boxes) - press enter (-> error message saying unlock failed) - after that, typing the password to unlock the screen works again
Created attachment 76743 [details] Rough patch, only use for testing! Works for me, but i've already added a patch to check for the window under the mouse (assuming the user will look there) and perform another explicit focus setting Please see and if you can try the attached patch. NOTICE that it includes "junk" (ie. hardcodes screensaver usage and makes the saver window distinguishable - so that i can try ;-)
Although at one point it seemed to be fixed, right now (in master) the focus is again not on the lineedit when pressing a key.
Still occurs in 4.10.1. Sometimes it works, sometimes it doesn't. It works most of the time when my cursor is on the primary screen, but it hardly works at all when my mouse is on the other screen.
What do you expect? I doesn't mystically fix itself. The bug will usually be closed with a fixing commit. Feel free to confirm or deny the attached patch.
Oh, I thought that patch has already been applied and the guy doing that just forgot the mention it in the commit message. When I read the discussion here I wasn't quite sure if that was already the case and it just didn't work out completely or just nothing had been done yet.
(In reply to comment #16) > > I'm sure you have more data about this issue than I do, but I fail to see > As we cannot know on which screen the user is looking, it makes more sense > to > just put an unlock window on each of it (yes we thought about that ;-) I don't follow this logic, at least not with how I am seeing it implemented (e.g., Fedora 20 with KDE 4.10.5). I have four 24" screens and now I don't know which, if any, will get the focus. I start typing my password and I have to scan four unlock windows to see my typing progress. The fact that none may have focus only makes the problem worse. Even if one did get focus, I still have to scan all four screens. Back when only one screen got the unlock window, it was readily apparent where "my focus" was required.
(In reply to comment #36) > I don't follow this logic, at least not with how I am seeing it implemented > (e.g., Fedora 20 with KDE 4.10.5). I have four 24" screens and now I don't > know which, if any, will get the focus. I start typing my password and I > have to scan four unlock windows to see my typing progress. Obviously the sane solution is to have all input windows visually reflect input - no matter where the focus actually is (iow: fake a focus everywhere) I take the actual problem is still present? Has anybody encountering it ever tried to fix it by the attached patch?
(In reply to comment #37) > (In reply to comment #36) > > > I don't follow this logic, at least not with how I am seeing it implemented > > (e.g., Fedora 20 with KDE 4.10.5). I have four 24" screens and now I don't > > know which, if any, will get the focus. I start typing my password and I > > have to scan four unlock windows to see my typing progress. > > Obviously the sane solution is to have all input windows visually reflect > input - no matter where the focus actually is (iow: fake a focus everywhere) Except that's not the course that was taken. > I take the actual problem is still present? Very much so as of KDE 4.10.5. I've not seen any form of improvement since this new type of screen saver came along. > Has anybody encountering it ever tried to fix it by the attached patch? Not here. I don't have time to rebuild, especially for something that is only going to fix a (very frequent) annoyance. I simply switched to xscreensaver, which works.
*** Bug 327566 has been marked as a duplicate of this bug. ***
screelocker multiscreen patch https://git.reviewboard.kde.org/r/113971/
Git commit 3a4a7ac959c17ffd08b104bc4c5d550b5f1dfcb6 by Thomas Lübking. Committed on 26/01/2013 at 21:27. Pushed by luebking into branch 'KDE/4.11'. improve screenlocker multiscreen behavior - pass focus to greeter under the mouse - share keyboard events - let through keyboard events for one hidden locker (mouse wakeup case) - remove double filtering FIXED-IN: 4.11.4 REVIEW: 113971 M +86 -6 ksmserver/screenlocker/greeter/greeterapp.cpp M +1 -0 ksmserver/screenlocker/greeter/greeterapp.h http://commits.kde.org/kde-workspace/3a4a7ac959c17ffd08b104bc4c5d550b5f1dfcb6