As seen in openQA, it's practically invisible: https://openqa.opensuse.org/tests/1399988#step/start_wayland_plasma5/16 Last good test run was 21 days ago: https://openqa.opensuse.org/tests/1378614#step/start_wayland_plasma5/16 Switching back to Plasma.Components 2.0 makes it appear again.
Can reproduce. I see some suspicious console spew: [11:40:51.660] (WW) GREETER: file:///home/nate/kde/usr/share/sddm/themes/breeze//components/VirtualKeyboard.qml:22:1: Type InputPanel unavailable [11:40:51.660] (WW) GREETER: qrc:/QtQuick/VirtualKeyboard/content/InputPanel.qml:127:5: Type Keyboard unavailable [11:40:51.660] (WW) GREETER: qrc:/QtQuick/VirtualKeyboard/content/components/Keyboard.qml:38:1: module "QtQuick.VirtualKeyboard.Plugins" is not installed [11:40:52.145] (WW) GREETER: <input>:406:376: Could not add child element to parent element because the types are incorrect. I'll see if I can fix it.
Oddly, it appears just fine on the lock screen.
Somehow the QtQuick virtual keyboard component is not loadable by the login screen the way it is by the lock screen.
No idea why exactly, but that (totally misleading) error goes away with QT_IM_MODULE=qtvirtualkeyboard.
If I export that envar, the problem is totally fixed in fact. The button appears and I can pull up the virtual keyboard. I also see that the screen locker is explicitly setting this environment variable: nate@Liberator:~/kde/src/kscreenlocker$ (master) grep -ri qtvirtualkeyboard greeter/main.cpp: qputenv("QT_IM_MODULE", QByteArrayLiteral("qtvirtualkeyboard")); ...But the same cannot be said of anywhere in plasma itself. So that's why it still works in the lock screen, but not the login screen. I wonder if this is in any way related to the work to make the Maliit virtual keyboard function properly.
It has come to my attention that I misunderstood the bug report, which was originally reporting Bug 426556. *** This bug has been marked as a duplicate of bug 426556 ***