STEPS TO REPRODUCE 1. boot 2. type your password in SDDM and press enter/return 3. OBSERVED RESULT nothing happens. I need to click on the button beside the password field to start Plasma. EXPECTED RESULT we can log in by pressing enter/return SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.91.90 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 Graphics Platform: X11
I checked for this and it's not happening in Fedora rawhide. FYI.
(In reply to Andres Betts from comment #1) > I checked for this and it's not happening in Fedora rawhide. FYI. I think Fedora uses wayland SDDM. Afaik this bug only affects X11. @Patrick Silva can you check if this also happens with kscreenlocker?
Can reproduce on neon unstable, with sddm using X11.
Confirmed. 5.91 on Archlinux.
(In reply to Sebastian Kuźlak from comment #4) > Confirmed. 5.91 on Archlinux. X11
*** Bug 479071 has been marked as a duplicate of this bug. ***
confirmed on: Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.91.90 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 Kernel Version: 6.2.0-39-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz Memory: 15,3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: Dell Inc. Product Name: XPS 13 9380
does not happen to me with kscreenlocker
(In reply to Dennis from comment #7) > confirmed on: > > Operating System: KDE neon Unstable Edition > KDE Plasma Version: 5.91.90 > KDE Frameworks Version: 5.248.0 > Qt Version: 6.6.1 > Kernel Version: 6.2.0-39-generic (64-bit) > Graphics Platform: Wayland > Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz > Memory: 15,3 GiB of RAM > Graphics Processor: Mesa Intel® UHD Graphics 620 > Manufacturer: Dell Inc. > Product Name: XPS 13 9380 Is your sddm using wayland or x11?
I use wayland (In reply to fanzhuyifan from comment #9) > (In reply to Dennis from comment #7) > > confirmed on: > > > > Operating System: KDE neon Unstable Edition > > KDE Plasma Version: 5.91.90 > > KDE Frameworks Version: 5.248.0 > > Qt Version: 6.6.1 > > Kernel Version: 6.2.0-39-generic (64-bit) > > Graphics Platform: Wayland > > Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz > > Memory: 15,3 GiB of RAM > > Graphics Processor: Mesa Intel® UHD Graphics 620 > > Manufacturer: Dell Inc. > > Product Name: XPS 13 9380 > > Is your sddm using wayland or x11? Wayland as far as I can see. I login with Wayland selected at least. I'm not sure if the system boots up with x11/wayland before logging in. I looked at the sddm config files, but no x11 is set. Let me know how I can check this further if you need to know more.
*** Bug 479348 has been marked as a duplicate of this bug. ***
Can confirm this on Neon with X11 SDDM and X11 kscreenlocker. Wayland SDDM and kscreenlocker works as expected. Oddly using the Enter button in the Virtualkeyboard also works as expected. I cannot reproduce this on Arch. Neither with testing/kdeunstable repos nor with normal Arch with build from source plasma 6.
I tried to install a VM with Neon unstable to reproduce on a clean system, but currently the Neon unstable iso's won't install a Virtualbox VM. it does not happen with kscreenlocker after I'm logged in, which would suggest my system boots with an X11 and switches to wayland after logging in.
I also had this issue - but reconfigured sddm to use Wayland (https://wiki.archlinux.org/title/SDDM#Running_under_Wayland) and the enter key works with SDDM on Wayland.
(In reply to Russ Hay from comment #14) > I also had this issue - but reconfigured sddm to use Wayland > (https://wiki.archlinux.org/title/SDDM#Running_under_Wayland) and the enter > key works with SDDM on Wayland. I'm running Plasma 6 Beta 2 on KDE Neon (unstable)
(In reply to Russ Hay from comment #15) > (In reply to Russ Hay from comment #14) > > I also had this issue - but reconfigured sddm to use Wayland > > (https://wiki.archlinux.org/title/SDDM#Running_under_Wayland) and the enter > > key works with SDDM on Wayland. > > I'm running Plasma 6 Beta 2 on KDE Neon (unstable) I tried it, but does not seem to work for me. I entered: [General] DisplayServer=wayland updated the system, rebooted but still no joy. /etc/sddm.conf is empty (0 bytes) /etc/sddm.conf.d/kde_settings.conf has just basic settings: [Autologin] Relogin=false Session= User= [General] HaltCommand= RebootCommand= [Theme] Current=breeze CursorSize= CursorTheme=breeze_cursors Font=Noto Sans,10,-1,0,400,0,0,0,0,0,0,0,0,0,0,1 [Users] MaximumUid=60000 MinimumUid=1000
(In reply to Dennis from comment #16) > (In reply to Russ Hay from comment #15) > > (In reply to Russ Hay from comment #14) > > > I also had this issue - but reconfigured sddm to use Wayland > > > (https://wiki.archlinux.org/title/SDDM#Running_under_Wayland) and the enter > > > key works with SDDM on Wayland. > > > > I'm running Plasma 6 Beta 2 on KDE Neon (unstable) > > I tried it, but does not seem to work for me. I entered: > [General] > DisplayServer=wayland > > updated the system, rebooted but still no joy. > > /etc/sddm.conf is empty (0 bytes) > /etc/sddm.conf.d/kde_settings.conf has just basic settings: > [Autologin] > Relogin=false > Session= > User= > > [General] > HaltCommand= > RebootCommand= > > [Theme] > Current=breeze > CursorSize= > CursorTheme=breeze_cursors > Font=Noto Sans,10,-1,0,400,0,0,0,0,0,0,0,0,0,0,1 > > [Users] > MaximumUid=60000 > MinimumUid=1000 in that wiki - these's section 2.12.1 which has the additional configuration needed for SDDM Wayland on kwin.
Ah yes, did read it but was not registered in my brain. My bad. I don't know too much on all the details, I was just reading up what a compositor was, weston vs kwin, etc. A bit new on this stuff all. I'm mainly here to report bugs and test, for all the rest im a newb. But it was fixed! For reference, my /etc/sddm.conf.d/10-wayland.conf contains now: [General] DisplayServer=wayland GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell [Wayland] CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1 Is this just a side effect from running unstable or does there need to be action for plasma6?
*** Bug 479441 has been marked as a duplicate of this bug. ***
*** Bug 479516 has been marked as a duplicate of this bug. ***
Seems like qt6-virtualkeyboard is related somehow. After removing it SDDM works as expected.
*** Bug 479911 has been marked as a duplicate of this bug. ***
Neon was updated to KDE 6.1 branch and there it is fixed.
(In reply to Dennis from comment #13) > I tried to install a VM with Neon unstable to reproduce on a clean system, > but currently the Neon unstable iso's won't install a Virtualbox VM. > > it does not happen with kscreenlocker after I'm logged in, which would > suggest my system boots with an X11 and switches to wayland after logging in. you need to enable 3d acceleration in the virtualbox display settings for the vm
*** Bug 480449 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/201
I'm not sure if it is useful information for tracking down the cause of this issue, but if you press tab to take focus from the input box to the button beside the field, and then press enter, it works. So the issue is specifically with the enter key not triggering the form from inside the input box. The enter key also does not "wake up" the screen from the inactive state (only showing the clock) to showing the login form. I wonder if the enter key might be registered as a shortcut on the application window itself, and having focus on the input field is blocking the shortcut from propagating to the window in X11.
Not X11 -specific. Happens also with Wayland on Virtualbox 0.20.0+p22.04+vunstable+git20240105.1213-0
(In reply to Lassi Väätämöinen from comment #28) > Not X11 -specific. Happens also with Wayland on Virtualbox I cannot repro in Wayland on hardware - which makes me thing the VirtualBox issue is a separate problem.
(In reply to Lassi Väätämöinen from comment #28) > Not X11 -specific. Happens also with Wayland on Virtualbox > > 0.20.0+p22.04+vunstable+git20240105.1213-0 I cannot reproduce in in Virtualbox with wayland. Can you tell me which distro you are seeing this? Or how to reproduce this on wayland?
See also: https://github.com/sddm/sddm/issues/1824 The enter key on the keypad works.
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3713
>I cannot reproduce in in Virtualbox with wayland. Can you tell me which distro you are seeing this? Or how to reproduce this on wayland? KDE Neon Unstable SDDM login: enter does not work, when focus is in the password entry box. You need to <tab> into the arrow button, then enter works. KScreenlocker: works.
(In reply to Lassi Väätämöinen from comment #33) > KDE Neon Unstable > SDDM login: enter does not work, when focus is in the password entry box. > You need to <tab> into the arrow button, then enter works. > KScreenlocker: works. Please note that SDDM default configuration is to run with X11 - even when you log in to a Wayland session, the SDDM login screen itself is running on X11, where the behavior described by this bug would happen. The workaround would be to run SDDM under Wayland, by having the following configuration in /etc/sddm.conf: ---8<--- [General] DisplayServer=wayland GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell [Wayland] CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1 ---8<--- If you don't have this configuration (or similar), then SDDM is running under X11 and this is problem is not actually happen with Wayland.
(In reply to fanzhuyifan from comment #32) > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3713 As discussed in the MR, the issue is that the virtual keyboard consumed events even though it was not shown on screen.
*** Bug 480876 has been marked as a duplicate of this bug. ***
Just for the record I can also reproduce this bug in both X11 and Wayland when running the latest KDE Neon unstable under QEMU. Here are the detailed specs: SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 6.0.80 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.1 Kernel version: 6.5.0-15-generic (64-bit) Graphics Platform: Wayland Tested in a Virtual Machine (in QEMU v4.0.0) with the following specs: Processor: 2 × Intel® Core™ i3-4150 CPU @ 3.50GHz Memory: 3.8 GiB of RAM Graphics Processor: llvmpipe Manufacturer: QEMU Product name: Standard PC (Q35 + ICH9, 2009) System version: pc-q35-6.2
(In reply to funkybomber from comment #37) > Just for the record I can also reproduce this bug in both X11 and Wayland > when running the latest KDE Neon unstable under QEMU. Can you please make sure that the Wayland issue is not as actually an X11 issue, as described in comment #34?
(In reply to Oded Arbel from comment #38) > (In reply to funkybomber from comment #37) > > Just for the record I can also reproduce this bug in both X11 and Wayland > > when running the latest KDE Neon unstable under QEMU. > > Can you please make sure that the Wayland issue is not as actually an X11 > issue, as described in comment #34? I followed your instructions and indeed you are correct. My etc/sddm.conf was missing the Wayland parameters. This bug is only affecting the X11 session. Under the Wayland session the SDDM screen login works fine. This begs the question why we wouldn't launch the Wayland SDDM screen by default? Less bug reports and less wasting everyone's time.
Unfortunately it's a distro decision and not a KDE decision. I know that Fedora KDE uses the Wayland SDDM by default now. If Neon doesn't, it would be reasonable to submit a bug report requesting that.
(In reply to Nate Graham from comment #40) > Unfortunately it's a distro decision and not a KDE decision. I know that > Fedora KDE uses the Wayland SDDM by default now. If Neon doesn't, it would > be reasonable to submit a bug report requesting that. I have been asking the Neon devs to consider this and they opened an issue: https://invent.kde.org/teams/neon/-/issues/154 The issue is that wayland SDDM is still experimental and there could potentially be issues with nvidia. Another workaround would be to not use the virtualkeyboard by default. Personally I hope this can be fixed before Plasma 6 launches, but if it does not there are a few workarounds (wayland ssdm, no virtual keyboard by default on sddm etc..)
@Carlos De Maine, Thank you for helping me with virtualbox and kde unstable. To confirm: - I could reproduce this in Virtualbox with kde unstable, source: neon-unstable-20231224-1120.iso - After updating to today's packages (6th of feb) the bug still exists.
I confirm I can reproduce this. The normal ENTER does not work, but the ENTER from the keypad does. I use Arch+Wayland on a multi-monitor configuration. It only happens with Breeze. I am using KDE 6 RC2.
*** Bug 481078 has been marked as a duplicate of this bug. ***
*** Bug 481148 has been marked as a duplicate of this bug. ***
*** Bug 481195 has been marked as a duplicate of this bug. ***
Perhaps this should be given the honour of being a 15 minute bug...
(In reply to tagwerk19 from comment #47) > Perhaps this should be given the honour of being a 15 minute bug... It has been for quite a while. Now it has even been bumped to VHI
(In reply to Dennis from comment #18) > But it was fixed! For reference, my /etc/sddm.conf.d/10-wayland.conf > contains now: > > [General] > DisplayServer=wayland > GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell > > [Wayland] > CompositorCommand=kwin_wayland --drm --no-lockscreen > --no-global-shortcuts --locale1 > > Is this just a side effect from running unstable or does there need to be > action for plasma6? On kde6 this option does not work now. I build a plasma package with parameter -DINSTALL_SDDM_WAYLAND_SESSION:BOOL=ON. With this parameter, the Wayland session does not load. But just delete the /etc/sddm.conf.d/plasma-wayland.conf file and the session will open.
(In reply to Victor Ryzhykh from comment #49) > With this parameter, the Wayland session does not load. > But just delete the /etc/sddm.conf.d/plasma-wayland.conf file and the > session will open. But I built it like this two months ago. Perhaps something has changed now.
The bug only happens in X when QtVirtualKeyboard is compiled with: FEATURE_vkb_arrow_keynavigation=ON A features that's off by default. The root cause is this event filter on the window: bool QVirtualKeyboardInputContextPrivate::filterEvent() { ... #ifdef QT_VIRTUALKEYBOARD_ARROW_KEY_NAVIGATION if ((key ... == Qt::Key_Return) { if (type == QEvent::KeyPress && platformInputContext->isInputPanelVisible()) { emit navigationKeyPressed(key, keyEvent->isAutoRepeat()); return true; the query of isInputPanelVisible is a check of Qt.inputMethod.visible (does something want text input), not a check of InputPanel.active (is the VK visible) which arguably it should be for our purposes. I would say our best bet is to just say this compile flag is unsupported and it is a downstream issue.
(In reply to David Edmundson from comment #51) > I would say our best bet is to just say this compile flag is unsupported and > it is a downstream issue. Then should we add that note to https://community.kde.org/Distributions/Packaging_Recommendations?
(In reply to David Edmundson from comment #51) > The bug only happens in X when QtVirtualKeyboard is compiled with: > FEATURE_vkb_arrow_keynavigation=ON > > A features that's off by default. How would you explain that this issue is reproducable on Neon, where qtvirtualkeyboard is built without this flag since September 15, 2022?
(In reply to Oded Arbel from comment #53) > (In reply to David Edmundson from comment #51) > > The bug only happens in X when QtVirtualKeyboard is compiled with: > > FEATURE_vkb_arrow_keynavigation=ON > > > > A features that's off by default. > > How would you explain that this issue is reproducable on Neon, where > qtvirtualkeyboard is built without this flag since September 15, 2022? Arrow key navigation works for me on Neon unstable.
(In reply to fanzhuyifan from comment #54) > Arrow key navigation works for me on Neon unstable. I'm not really sure what the is vkb-arrow-keynavitation feature behavior. I'm not using the virtual keyboard at all (specifically when I press the "Virtual Keyboard" button nothing happens - I have qt6-virtualkeyboard 6.6.1-0xneon+22.04+jammy+stable+build22 installed), and for me arrow keys in SDDM select the user to log in as (left/right, the up/down keys do nothing).
(In reply to fanzhuyifan from comment #54) > Arrow key navigation works for me on Neon unstable. Tested in KVM guests ... ... both Neon Testing(*) and Neon Unstable seem to need the mouse or a "tab" to jump to the "enter" button. The keypad "enter" key works for both. I don't see the arrow keys doing anything - except with the on-screen keyboard where they work fine. My Neon Testing may not be fully updated, discover/pkcon update crashes out with Bug 480704
(In reply to Oded Arbel from comment #53) > (In reply to David Edmundson from comment #51) > > The bug only happens in X when QtVirtualKeyboard is compiled with: > > FEATURE_vkb_arrow_keynavigation=ON > > > > A features that's off by default. > > How would you explain that this issue is reproducable on Neon, where > qtvirtualkeyboard is built without this flag since September 15, 2022? I think neon unstable, stable, and release are all built with this flag: https://invent.kde.org/neon/qt6/qt6-virtualkeyboard/-/blob/Neon/unstable/debian/rules?ref_type=heads#L25 https://invent.kde.org/neon/qt6/qt6-virtualkeyboard/-/blob/Neon/stable/debian/rules?ref_type=heads#L25 https://invent.kde.org/neon/qt6/qt6-virtualkeyboard/-/blob/Neon/release/debian/rules?ref_type=heads#L25
offending build removed - https://invent.kde.org/neon/qt6/qt6-virtualkeyboard/-/commit/7adcd249658792a2fc2bae307601aa3fde656dfe new packages uploaded. can anyone upgrade and confirm that this issue is now fixed??
(In reply to Carlos De Maine from comment #58) > offending build removed - > https://invent.kde.org/neon/qt6/qt6-virtualkeyboard/-/commit/ > 7adcd249658792a2fc2bae307601aa3fde656dfe > new packages uploaded. can anyone upgrade and confirm that this issue is > now fixed?? Can confirm the fix on neon unstable. Thank you! can also confirm this fixes the issue on arch linux with custom qt6-virtualkeyboard build.