SUMMARY *** both on login screen and in screenlock, you have tu use the mouse to focus in the box, to type the password *** STEPS TO REPRODUCE 1. restart (or start) the PC 2. at the login you cannot use the keyboard: not working; you must use the mouse to focus on the password box 3. at the end, after focusing, you can type the password OBSERVED RESULT I have said it. EXPECTED RESULT As ever on the past, you could use the only keyboard, and not also the mouse, before the keyboard SOFTWARE/OS VERSIONS Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.3 Kernel Version: 5.13.0-28-generic (64-bit) Graphics Platform: X11 Processors: 2 × Intel® Core™ i3-7100 CPU @ 3.90GHz Memory: 7,7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 ADDITIONAL INFORMATION KDE Neon
Hello, it works fine for me. I can type the password without the mouse focus. It works in both. Screen lock and login. I'm using Kubuntu 21.10 plasma 5.24.0 Regards
Maybe is a problem only in KDE Neon?
I tried with VM KDE Neon latest 5.24.00. it works again. I would wait if someone else can confirm the issue.
It seems that here there is a duplicate: https://bugs.kde.org/show_bug.cgi?id=433054
I mean #68: https://bugs.kde.org/show_bug.cgi?id=433054#c68
*** This bug has been marked as a duplicate of bug 433054 ***
To be honest I'm not sure. the original issue is about to not be able to unlock the screen
Are you using a 3rd-party Plasma theme? If not, then this can't be the same as Bug 433054, because that's about code errors in 3rd-party lock screens breaking screen unlocking.
actually it was working for me because I was using third party login screen. If change to default one(Breeze), I need to click on the box in order to type the password.
Oh, that's a different thing then.
Can you reproduce the issue with "sddm-greeter --theme /usr/share/sddm/themes/breeze --test-mode"? What's the output? Is the cursor vieibls in the password field? If yes, does it blink?
I tried again with previous login screen and now the issue doesn't go away. So it must be related to the new config that the login screen(SDDM) is applying.
sddm-greeter --theme /usr/share/sddm/themes/breeze --test-mode [20:33:43.070] (II) GREETER: High-DPI autoscaling not Enabled [20:33:43.141] (II) GREETER: Reading from "/usr/share/xsessions/plasma.desktop" [20:33:43.142] (II) GREETER: Reading from "/usr/share/xsessions/plasmax11-dev.desktop" [20:33:43.142] (II) GREETER: Reading from "/usr/share/wayland-sessions/plasmawayland-dev.desktop" [20:33:43.142] (II) GREETER: Reading from "/usr/share/wayland-sessions/plasmawayland.desktop" [20:33:43.143] (II) GREETER: Loading theme configuration from "/usr/share/sddm/themes/breeze/theme.conf" [20:33:43.153] (EE) GREETER: Socket error: "QLocalSocket::connectToServer: Invalid name" [20:33:43.153] (WW) GREETER: QFont::fromString: Invalid description '(empty)' [20:33:43.209] (II) GREETER: Loading file:///usr/share/sddm/themes/breeze/Main.qml... [20:33:43.717] (WW) GREETER: file:///usr/share/sddm/themes/breeze/components/VirtualKeyboard.qml:11:1: Type InputPanel unavailable [20:33:43.717] (WW) GREETER: qrc:/QtQuick/VirtualKeyboard/content/InputPanel.qml:127:5: Type Keyboard unavailable [20:33:43.717] (WW) GREETER: qrc:/QtQuick/VirtualKeyboard/content/components/Keyboard.qml:38:1: module "QtQuick.VirtualKeyboard.Plugins" is not installed [20:33:43.795] (II) GREETER: Adding view for "HDMI-0" QRect(0,0 1920x1080) [20:33:43.798] (II) GREETER: Loading file:///usr/share/sddm/themes/breeze/Main.qml... [20:33:43.819] (WW) GREETER: QQmlEngine::setContextForObject(): Object already has a QQmlContext [20:33:43.821] (WW) GREETER: QQmlEngine::setContextForObject(): Object already has a QQmlContext [20:33:43.849] (WW) GREETER: file:///usr/share/sddm/themes/breeze/components/VirtualKeyboard.qml:11:1: Type InputPanel unavailable [20:33:43.849] (WW) GREETER: qrc:/QtQuick/VirtualKeyboard/content/InputPanel.qml:127:5: Type Keyboard unavailable [20:33:43.849] (WW) GREETER: qrc:/QtQuick/VirtualKeyboard/content/components/Keyboard.qml:38:1: module "QtQuick.VirtualKeyboard.Plugins" is not installed [20:33:43.854] (II) GREETER: Adding view for "eDP-1-1" QRect(1920,0 1920x1080) [20:33:43.913] (WW) GREETER: <input>:303:258: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:463: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:659: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:913: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:1049: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:1251: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:1453: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:1631: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:1739: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:1980: Could not add child element to parent element because the types are incorrect. [20:33:43.913] (WW) GREETER: <input>:303:2223: Could not add child element to parent element because the types are incorrect.
apt search qml-module-qtquick-virtualkeyboard Sorting... Done Full Text Search... Done qml-module-qtquick-virtualkeyboard/impish,now 5.15.2+dfsg-2 amd64 [installed,automatic] Qt virtual keyboard - QML module
Sorry, I can type the password with that mode.
resume in my case. 1- it was working fine for me until I applied Breeze login screen. 2- Now I see the issue with logic screen 3- the tex box doesn't get selected when plug-in my second monitor. My working system is a laptop and external monitor(primary). 4. I'm using x11. 5. It doesn't matter if I change the primary monitor. It text box is unselected any ways.
*** Bug 450081 has been marked as a duplicate of this bug. ***
This happens to me when a screen is removed. You then have to focus the passwort input box to be able to input the password.
For people experiencing this, do you have multiple monitors, or just one?
(In reply to Nate Graham from comment #19) > For people experiencing this, do you have multiple monitors, or just one? Just one.
(In reply to Nate Graham from comment #19) > For people experiencing this, do you have multiple monitors, or just one? Three: unplugging two, so that only one remains.
In my case I have 2. The laptop and an external monitor. When disconnect the external monitor the text field is auto selected as normal
So I can understand better: does this issue refer to a requirement to click the password field before entering any password or is it just referring to moving the mouse to bring the password field into focus? If the former, then this a new issue and I'm not affected. If it's only the latter, then that sounds like bug 439604 to me. For whatever it's worth, for the latter case, I find that occurring with one and two monitors across multiple systems with the same Plasma updates installed.
(In reply to Wedge009 from comment #23) > So I can understand better: does this issue refer to a requirement to click > the password field before entering any password or is it just referring to > moving the mouse to bring the password field into focus? > > If the former, then this a new issue and I'm not affected. If it's only the > latter, then that sounds like bug 439604 to me. For whatever it's worth, for > the latter case, I find that occurring with one and two monitors across > multiple systems with the same Plasma updates installed. Sorry, but I don't understand your alternative: what do you mean. I can add that, on another, pc I saved the folder /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/, and pasting it in the other pc, I have now solved the focus issue for the screenlock, but not for the login.
What do you mean by regaining 'focus'? Is it just a matter of moving the mouse or are you needing to click the password field as well?
I tested this with a multimonitor setup on Wayland and was unable to reproduce the problem there either. Even when the main UI was invisible, typing made it appear and the keystrokes were correctly forwarded to the password field on one of the screens. Is everyone affected by this actually using the Breeze, Breeze Light, or Breeze Dark Plasma theme? if so, which one? If everyone affected by this using X11?
in my case it started the issue when I reassigned Breeze login screen as I was using a third party one. the lock screen is fine for me. I'm using X11
(In reply to Wedge009 from comment #25) > What do you mean by regaining 'focus'? Is it just a matter of moving the > mouse or are you needing to click the password field as well? the second alternative: click the password field as well. I am x11, and breeze theme.
OK, let me try with X11 later today...
I can't reproduce the issue with 1 or 2 monitors on X11 either. Typing text makes the main UI appear and the text is entered in the password field as I would expect.
(In reply to Nate Graham from comment #30) > I can't reproduce the issue with 1 or 2 monitors on X11 either. Typing text > makes the main UI appear and the text is entered in the password field as I > would expect. Have you read this (#26)? "I can add that, on another, pc I saved the folder /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/, and pasting it in the other pc, I have now solved the focus issue for the screenlock, but not for the login."
sorry, #24
Hi Nate, did you try assigning a third-party SDDM theme and the back to default Breeze?
(In reply to Duns from comment #31) > "I can add that, on another, pc I saved the folder > /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/, and pasting it in > the other pc, I have now solved the focus issue for the screenlock, but not > for the login." This would imply a packaging issue, with some files not being fully updated. Perhaps reinstalling plasma-workspace would help? Or applying today's Plasma 5.24.1 update? Also, let's not confuse ourselves here; this bug report is about the lock screen, not the login screen; they are different. If any of you experience that both exhibit the bug, we need a new bug report for that.
So, I made a quick video (sorry for the poor quality, screen recording did not work while unplugging a screen and I don't have the most steadiest hands): https://youtu.be/wn6hZh9GrLY You can see the lockscreen first correctly has the focus for the password input (I moved the mouse cursor so you can see it). Then I unplug the screens. Then I move the mouse cursor to show the UI again, but the bug would also happen without this step. Then I press some keys, the password input is not focused. Then I click into the password input, now everything works correctly. Operating System: Arch Linux KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.9-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620
(In reply to Duns from comment #28) > the second alternative: click the password field as well. In that case, Plasma 5.24 is a further regression from Plasma 5.18.8. Nate has declared we should continue the conversation from bug 439604 here, since Plasma 5.18.x is no longer supported. However, I haven't yet had to click to gain password input focus. Looks like I won't encounter Plasma 5.24 until the next Kubuntu LTS scheduled in a couple of months from time of writing. I am also still on X11, and as stated previously, using both single and dual monitor configurations on at least three separate PCs with default Kubuntu theme which I think is mostly based on the default KDE Breeze theme.
I continue to be unable to reproduce the issue with the default Breeze Plasma theme no matter how I try. There was actually a packaging issue in 5.24 that caused some commits to be omitted, but it was all cleared up for 5.24.1. I wonder if there's a chance the fix was one of the omitted commits. So I'd like to ask folks if they are still seeing it with 5.24.1.
(In reply to Nate Graham from comment #37) > So I'd like to ask folks if they are still seeing it with 5.24.1. Just tried, it still happens to me with 5.24.1
OK, thanks. Would you mind making taking a shakycam phone video that shows the issue happening, as well as what your hands are doing on the keyboard and mouse/touchpad? I'd really appreciate that and I think it might shed some light on the issue.
(In reply to Nate Graham from comment #39) > Would you mind making taking a shakycam phone video that shows the issue > happening, as well as what your hands are doing on the keyboard and > mouse/touchpad? I'd really appreciate that and I think it might shed some > light on the issue. Well, there you go: https://www.youtube.com/watch?v=Pp6TYMuEPUI
to me happens in the external monitor(primary), the laptop monitor is fine.
Thank you! Looks like we have exactly the same hardware lol. So that isn't it either. Does the bug reproduce when you boot the machine with no external monitors attached, rather than disconnecting them while it's already on?
The cursor not blinking means that the text input is focused, but it doesn't have active focus, most likely because the window isn't focused. I can reproduce the issue in a VM with multihead-QXL (needs virt-viewer instead of virt-manager): 1. Lock the screen with just display 1 active 2. Enable display 2 3. Only one of the lockscreen views has focus (as expected), disable the screen with the focused one 4. The view remains unfocused By connecting to view's activeChanged() signal, it's visible that it never gets focus. Explicitly calling requestActiveFocus after view removal doesn't help either. FWICT, that the lockscreen isn't focused after screen removal is a bug in KWin. I can't reproduce that with kscreenlocker_greet --testing, so it might be in screenlock specific code. No idea about the more general issue reported initially that there's no focus at all. That could've been caused by a packaging issue indeed.
In several Pc I have only one monitor, and I have this bug
*** Bug 450753 has been marked as a duplicate of this bug. ***
Please do not move bugs to kwin unless kwin is at fault.
Comparing the older files on my desktop with the newer ones on my laptop that display the bug, I believe I have found the source of the problem. Between the two, looking at the changes to /usr/share/plasma/look-and-feel/, the only changes other than metadata.{desktop,json} localization changes were in /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml, which added the lines below. Reverting to the old file from my desktop fixed the bug (i.e. removing the lines setting visible and enabled), and I can now enter text on the lock screen without having to hit tab a few times and/or moving the mouse. --- /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml-old +++ /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml-new @@ -227,6 +227,12 @@ height: lockScreenRoot.height + units.gridUnit * 3 focus: true //StackView is an implicit focus scope, so we need to give this focus so the item inside will have it + // this isn't implicit, otherwise items still get processed for the scenegraph + visible: opacity > 0 + // changing enabled will toggle if an item can have activeFocus, which otherwise + //keeps the text cursor blinking even when invisble + enabled: visible + initialItem: MainBlock { id: mainBlock lockScreenUiVisible: lockScreenRoot.uiVisible My laptop (as it's not the most recent version of Plasma, so it could be different now): Linux/KDE Plasma: Kubuntu 20.04 KDE Plasma Version: 5.18.8 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8
Interesting. I confirm that removing those lines also resolves the issue for me, at least what is reported in bug #439604. I am also using Kubuntu 20.04, so am using Plasma 5.18 not 5.24.
It looks like only the 'enabled: visible' line is relevant here. I reinstated 'visible: opacity > 0' and I still get the desired historical behaviour of keyboard inputs feeding straight into the password input field. The reason I find this noteworthy is because this matches the current state of LockScreenUi.qml in master: https://invent.kde.org/plasma/plasma-workspace/-/blob/master/lookandfeel/contents/lockscreen/LockScreenUi.qml The same is true for 5.24 branch: https://invent.kde.org/plasma/plasma-workspace/-/blob/Plasma/5.24/lookandfeel/contents/lockscreen/LockScreenUi.qml If developers aren't observing the broken behaviour, maybe this is why? Plasma 5.18 branch still retains the 'enabled: visible' line: https://invent.kde.org/plasma/plasma-workspace/-/blob/Plasma/5.18/lookandfeel/contents/lockscreen/LockScreenUi.qml#L234 I understand 5.18 is no longer being maintained. BTW, I'm not sure what either of these lines in the QML do, I'm just reporting my observations as a user.
I apologise if this was already discussed in these bug reports but the fix was applied to master with MR 561: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/561 Commentary suggests some reason this could not be applied to 5.18 branch.
(In reply to Wedge009 from comment #50) > I apologise if this was already discussed in these bug reports but the fix > was applied to master with MR 561: > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/561 > > Commentary suggests some reason this could not be applied to 5.18 branch. Yeah, that requires porting the textfield to QQC2 first, so it had to be reverted in 5.18 (c4a3a4e5b974fb309a6da61252b2b830d2d90683). That commit fixed 697b103f5fad5b40b207eabcbce162d6672f5d91, so that should've been reverted as well as the fix couldn't be used. However, all of this is specific to 5.18.7, while this bug report is initially about 5.24.
I can confirm that commenting out "enabled: visible" from /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml solves the issue for me. I'm running: Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.8 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-104-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz Memory: 15,3 GiB of RAM
(In reply to Fabian Vogt from comment #51) > However, all of this is specific to 5.18.7, while this bug report is > initially about 5.24. I understand that, but if you look at the original bug report for Plasma 5.18, bug #439604, we were informed that since 5.18 is no longer maintained we should continue the discussion in this report for Plasma 5.24.
I'm a little confused now. Are we talking about a problem that: 1. Affects both 5.18 and 5.24 2. Used to affect 5.24 and was since fixed, but still affects 5.18
I can only speak for myself, but it sounds like the same also applies to Maciej and Nathan: I am referring to the issue introduced in Plasma 5.18.7 where keyboard input ceased to show the unlock screen (this was originally reported in bug #439604). The recent discussion since 17th March 2022 shows this line is the culprit: https://invent.kde.org/plasma/plasma-workspace/-/blob/Plasma/5.18/lookandfeel/contents/lockscreen/LockScreenUi.qml#L234 The other issue, which seems to be related yet distinct, is the issue that the original reporter Duns (and others) is having with Plasma 5.24 where not only is the unlock screen only shown with mouse movement, but the password input needs to be clicked on in order give input (if I understand the report correctly). Since I am still on Plasma 5.18 I cannot comment on this particular aspect, at least not until I migrate to the next Kubuntu LTS which, at time of writing, is slated to use Plasma 5.24.3: https://packages.ubuntu.com/jammy/plasma-workspace-data
*** Bug 451614 has been marked as a duplicate of this bug. ***
Others in this thread pointed out the piece of code that is responsible (/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:231), which makes a lot of sense: > visible: opacity > 0 > enabled: visible Set visible to true if the it is not transparent. Enable when visible. This seems to be introduced in https://invent.kde.org/plasma/plasma-workspace/-/commit/c4a3a4e5b974fb309a6da61252b2b830d2d90683 with comment: > // changing enabled will toggle if an item can have activeFocus, which otherwise > //keeps the text cursor blinking even when invisble I however changed `enabled: visible` to `enabled: true` and (as expected) this restored the behavior for me. I do not see any evidence of a blinking cursor. I don't have any understanding of versioning or policy. I am on Kubuntu 20.04 and there are no updates in the Updates tab of Discover. The kinfocenter tells me I am on version 5.18.8 for the KDE Plasma. It would be nice (at least for other people who did not yet find this thread) to update the line, but as I said, I am not sure if the policy allows such a change
You'll need to upgrade on the command-line; I believe the GUI updater only shows you the upgrade to a new LTS version once its first bugfix release has come out.
The "enabled: visible" line in the code that is causing this bug has been removed on both the Plasma 5.24 and 5.24 branches in git, which will cause the Breeze lock screen to fall back to the default enabled value of true. So the bug should be fixed now for folks who use the next versions of each of those releases (5.24.6 and 5.25, respectively). Hopefully.
I previously linked the wrong commit, this is the one that introduced to it to this version: https://invent.kde.org/plasma/plasma-workspace/-/commit/c4a3a4e5b974fb309a6da61252b2b830d2d90683 This was a revert of https://invent.kde.org/plasma/plasma-workspace/-/commit/13057013d55ae19e76d29b9edc96510e52da2a7a Which was a 'fix' of https://invent.kde.org/plasma/plasma-workspace/-/commit/45e0a722fb85bb5d1ab8bef92080e934254b13aa where it was introduced as an 'optimization'. What I don't understand is how it can be that it manifested only a few months ago in 20.04. And if I understand you correctly you are saying this will not be fixed in 20.04. Maybe naive, but I don't understand why.
(In reply to Erik from comment #60) > And if I understand you correctly you are saying this will not be fixed in > 20.04. Maybe naive, but I don't understand why. It's because the Kubuntu people control what code goes into Kubuntu 20.04, not us in KDE. If they want the fix in 20.04 (It is a Kubuntu LTS edition, after all), they'll have to backport the fix. Since they're shipping it as an LTS, it's their responsibility to backport bugfixes that have already been fixed in newer versions.
*** Bug 454184 has been marked as a duplicate of this bug. ***
*** Bug 451273 has been marked as a duplicate of this bug. ***
*** Bug 460196 has been marked as a duplicate of this bug. ***
Hi all, is this bug supposed to have been fixed? I am on X11 and using KDE 5.2.5 and the error still persists for me, see: https://bugs.kde.org/show_bug.cgi?id=460196 Rik
(In reply to rik from comment #65) > Hi all, > is this bug supposed to have been fixed? I am on X11 and using KDE 5.2.5 and > the error still persists for me, see: > https://bugs.kde.org/show_bug.cgi?id=460196 > > Rik 5.25.5
What distro are you using?
(In reply to Nate Graham from comment #67) > What distro are you using? Kubuntu 22.04
Have a look at the commits linked by Erik on 2022-05-19. I recall manually deleting the 'enabled: visible' line when I was still on Kubuntu 20.04. I'm currently on Kubuntu 22.04 - I assume a fresh installation of Kubuntu 22.04 wouldn't have this issue, but I suppose it's possible the issue may linger for upgrades from 20.04.
OK I will. For info, i just did a fresh install of 22.04 this week with the latest version from Kubuntu, Rik
Could it be that /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml is not properly upgraded in Kubuntu? in my case I upgraded my Kubuntu system from 21.10 to 22.04 and I didn't have this issue.
Hi, 1. I hereby confirm that the words "enabled: visible" are no longer present in the /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml file on a fresh 22.04.01 Kubuntu installation 2. I still have this issue, but as noted in my original bug request (https://bugs.kde.org/show_bug.cgi?id=460196), the issue only arises when I connect my laptop to an external monitor - without the external monitor it works fine. The problem is I work with an external monitor 95% of the time. Rik
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!