Bug 427972

I can confirm this problem. Tested on latest KDE Neon (Wayland) with Plasma 5.20.1.

- The keyboard does not work at all if you activate it from the respective tray icon. "On-Screen keyboard Activated" popup is shown though.

- If you run it manually with "QT_IM_MODULE=qtvirtualkeyboard" variable, in many applications it just disappears immediately after clicking on some text field.

- If you run "systemsettings5" with this variable, the window and keyboard flashes constantly and this error is repeatedly displayed in the console:
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ApplicationItem.qml:0: ReferenceError: bottomMargin is not defined

I just wanted to say that the virtual keyboard is a mandatory feature for any DE and should be available and work everywhere, whether it is the login screen, lock screen, gtk or qt or another application or the DE itself. I am surprised that KDE on X11 doesn't have a built-in virtual keyboard and on Wayland it's completely broken too.

Virtual keyboard on the login screen and Onboard already installed on X11 once saved me from buying an external keyboard when I spilled water on my laptop (I was able to type everything with touchpad for some time).

Hi all,
I can confirme the bug, with Archlinux, plasma-desktop 5.20.1 and Qt 5.15.1.

The built-in keyboard was dropped in 5.20 in favor of external virtual keyboards. @Bhushan could provide more details.

(In reply to Vlad Zahorodnii from comment #4)
> The built-in keyboard was dropped in 5.20 in favor of external virtual
> keyboards. @Bhushan could provide more details.

Can we have more details about it.

Otherwise, I found another solution to make work another virtual keyboard under Wayland. I use Qtvkbd. It is a virtual keyboard who was make for Xorg/X11 but it can be used under Wayland.

The solution to use Qtvkbd on Wayland is :

1. Install or compile Qtvkbd. The source code is here: https://github.com/Alexander-r/qtvkbd

Note: For people using Arch or Manjaro, there is a AUR package here: https://aur.archlinux.org/packages/qtvkbd/

2. Edit /etc/environment file and add these lines :

QT_XCB_GL_INTEGRATION=xcb_egl 
QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=xcomposite-egl
QT_QPA_PLATFORM=xcb

3. Logout the session and then login.

4. Launch Qtvkbd.

Note: Qtvkbd is more powerfull then the default virtual keyboard. I would like to see it ported under Wayland and KDE.

(In reply to Vlad Zahorodnii from comment #4)
> The built-in keyboard was dropped in 5.20 in favor of external virtual
> keyboards. @Bhushan could provide more details.

What does this mean? As far as I know, there aren't any external virtual keyboards that work with Wayland. Also, the virtual keyboard indicator in 5.20 reads "Enabled" when I detach my external (physical) keyboard. Why would something enable that's not there? 

Wayland is supposed to be great for tablets and HiDPI displays. However, I can't use Plasma's Wayland session on my tablet as a daily driver because of the lack of a functioning virtual keyboard.

BTW, I can confirm this bug also on a Surface Pro 4. The virtual keyboard won't show anymore in Wayland or work with any app.

(In reply to kelnio@yahoo.com from comment #6)
> (In reply to Vlad Zahorodnii from comment #4)
> > The built-in keyboard was dropped in 5.20 in favor of external virtual
> > keyboards. @Bhushan could provide more details.
> 
> What does this mean? As far as I know, there aren't any external virtual
> keyboards that work with Wayland. Also, the virtual keyboard indicator in
> 5.20 reads "Enabled" when I detach my external (physical) keyboard. Why
> would something enable that's not there? 
> 
> Wayland is supposed to be great for tablets and HiDPI displays. However, I
> can't use Plasma's Wayland session on my tablet as a daily driver because of
> the lack of a functioning virtual keyboard.
> 
> BTW, I can confirm this bug also on a Surface Pro 4. The virtual keyboard
> won't show anymore in Wayland or work with any app.

For now, I use Qtvkbd who works on Xorg and Wayland (if you follow the solution I gave above). I tried qtvkbd on the login screen and it works but I can't use it with the InputMethod line found in the sddm.conf file (so I don't have the option in the lower left corner to enable qtvkbd on the login screen). If a kde developer can tell us a method to use another Virtual Keyboard with sddm.conf, I'll take it.

Qtvkbd is better than the default virtual keyboard.

As qtvkbd can't be used correctly under wayland. Qt5-virtualkeyboard is necessary under Wayland. There is no other alternative at this time.

(In reply to Vlad Zahorodnii from comment #4)
> The built-in keyboard was dropped in 5.20 in favor of external virtual
> keyboards. @Bhushan could provide more details.

Can @Bhushan give us more details about that information ? 

There is no other alternative that the built-in keyboard under Wayland.

The only alternative I use is Qtvkbd but it is only work under Xorg/X11. I tried it under Wayland but it doesn't as good as under Xorg/X11 because it is made for that one and not for Wayland.

Also, it causes me problems with automatic screen rotation under Wayland.

In 5.20 we replaced the builtin hardcoded QtVirtualKeyboard with an implementation of the input method wayland protocol (https://github.com/wayland-project/wayland-protocols/blob/master/unstable/input-method/input-method-unstable-v1.xml). In principal that allows any compliant keyboard to work. For Plasma Mobile we use Maliit (http://maliit.github.io/). "there aren't any external virtual keyboards that work with Wayland" is therefore not true.

However, the keyboard to be used needs to be specified when starting KWin, which we do for Mobile, but not on the desktop. Therefore it does not work on the desktop currently.

A simple solution would be to hardcode maliit like we do on mobile and require distros to ship it, but a more flexible approach would be nicer.

Right, that's not good. I'll look into it.

Here's a first approach to it, largely untested and with some reserves explained in the description for further discussion.
https://invent.kde.org/plasma/kwin/-/merge_requests/565

(In reply to Nicolas Fella from comment #10)
> In 5.20 we replaced the builtin hardcoded QtVirtualKeyboard with an
> implementation of the input method wayland protocol
> (https://github.com/wayland-project/wayland-protocols/blob/master/unstable/
> input-method/input-method-unstable-v1.xml). In principal that allows any
> compliant keyboard to work. For Plasma Mobile we use Maliit
> (http://maliit.github.io/). "there aren't any external virtual keyboards
> that work with Wayland" is therefore not true.
> 
> However, the keyboard to be used needs to be specified when starting KWin,
> which we do for Mobile, but not on the desktop. Therefore it does not work
> on the desktop currently.
> 
> A simple solution would be to hardcode maliit like we do on mobile and
> require distros to ship it, but a more flexible approach would be nicer.

Nicolas, what external keyboard could I, a user, install from my distribution's packaging system (using apt, pkcon, or pacman) that will work with KDE Plasma's Wayland session by default? 

Xorg has several virtual keyboards (I use Onboard) that have packages for multiple distributions that are easy to install and use. The even have GUIs for configuration and system tray indicators. Wayland has none. 

I compiled the maliit-keyboard-git (https://github.com/maliit/keyboard) from the AUR on Manjaro KDE yesterday. There was no configuration GUI or any instructions on how to get it to work. I ran it from a konsole in a Plasma Wayland session. I got some output with no warnings to indicate that it was not working properly, but the keyboard did not appear nor did it appear for any input fields.

I neither now every keyboard there is nor what distribution you use or what is available there. In terms of keyboard I know of Maliit and weston-keyboard. There is also Squeekboard, but I don't know if it implements the required protocols.

However none of those will work "by default" since, like I mentioned earlier, Plasma needs to be instructed which keyboard to use. This is currently very impractical, but Aleix' merge request will make that easier

(In reply to Nicolas Fella from comment #14)
> I neither now every keyboard there is nor what distribution you use or what
> is available there. In terms of keyboard I know of Maliit and
> weston-keyboard. There is also Squeekboard, but I don't know if it
> implements the required protocols.
> 
> However none of those will work "by default" since, like I mentioned
> earlier, Plasma needs to be instructed which keyboard to use. This is
> currently very impractical, but Aleix' merge request will make that easier

Nicolas, I apologize if I sounded snippy. I'm just frustrated that a solution to fix virtual keyboard support in Plasma mobile (which most of us don't use) has caused issues with virtual keyboard support on the Plasma desktop (which most of use do use). It looks like there is a fix/solution coming. However, until the fix/solution is implemented, those of us with tablets who rely on the virtual keyboard cannot use the Plasma Wayland session for any version of 5.20 (since the desktop is near impossible to use without a keyboard!). This is heartbreaking, as Plasma Wayland has improved significantly since the release of 5.20.

Git commit 05ebe676d2f6c5cabd4979b849e09703a55c93d2 by Aleix Pol Gonzalez, on behalf of Aleix Pol.
Committed on 18/01/2021 at 16:43.
Pushed by apol into branch 'master'.

Introduce a setting to specify an input method

At the moment we are getting the input method from the command line
which is not very handy (but very secure).
This patch changes it so it can be specified from a configuration
setting.

M  +3    -0    kwin.kcfg
M  +68   -33   main_wayland.cpp
M  +6    -0    main_wayland.h

https://invent.kde.org/plasma/kwin/commit/05ebe676d2f6c5cabd4979b849e09703a55c93d2

With the patch above, this becomes not a high priority issue. A solution is available that provides better virtual keyboards.

Just some minor UI left and maybe some distro communication.

(In reply to David Edmundson from comment #17)
> With the patch above, this becomes not a high priority issue. A solution is
> available that provides better virtual keyboards.
> 
> Just some minor UI left and maybe some distro communication.

Is this really a "solution?" From my understanding it's a patch to enable users like myself to select our own virtual keyboard solution. However, the list of virtual keyboards that support Wayland can be counted on one finger (Maliit), and no one has yet explained to average desktop users how to get Maliit up and running (I asked this question in December and got no reply). Plus, you really can't expect other distributions to pick up the slack and add support for this when the KDE Project's own (non) distro, KDE Neon, currently (as of 5.21) doesn't have this patch, or virtual keyboards that support Wayland, built in. 

Tablet users like myself haven't been able to use the Plasma Wayland session without lugging around an external keyboard since this was broken.

This should probably be linked here: https://invent.kde.org/plasma/kwin/-/wikis/Virtual-Keyboard

(In reply to Zamundaaa from comment #19)
> This should probably be linked here:
> https://invent.kde.org/plasma/kwin/-/wikis/Virtual-Keyboard

I jumped ship back to Ubuntu (KDE Neon) after having one too many problems with Manjaro. Can someone please explain how to install maliit in Ubuntu? I keep getting this error:

CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find QtWaylandScanner (missing: QtWaylandScanner_EXECUTABLE)
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindQtWaylandScanner.cmake:75 (find_package_handle_standard_args)
  CMakeLists.txt:53 (find_package)

I can't find a qtwaylandscanner package anywhere in the repositories..

(In reply to Zamundaaa from comment #19)
> This should probably be linked here:
> https://invent.kde.org/plasma/kwin/-/wikis/Virtual-Keyboard

I installed maliit in OpenSUSE Tumbleweed (https://software.opensuse.org/package/maliit-keyboard2) and followed the wiki and the keyboard is still not working.

(In reply to kelnio@yahoo.com from comment #20)
> I can't find a qtwaylandscanner package anywhere in the repositories..

qtwaylandscanner is apparently in the package qtwayland5

(In reply to Aitor from comment #21)
> I installed maliit in OpenSUSE Tumbleweed
> (https://software.opensuse.org/package/maliit-keyboard2) and followed the
> wiki and the keyboard is still not working.

The patch hasn't been in Maliit that long, it will take a bit until it reaches distro repos. Either wait for that to happen or compile it yourself.

(In reply to Zamundaaa from comment #22)
> (In reply to kelnio@yahoo.com from comment #20)
> > I can't find a qtwaylandscanner package anywhere in the repositories..
> 
> qtwaylandscanner is apparently in the package qtwayland5
> 
> (In reply to Aitor from comment #21)
> > I installed maliit in OpenSUSE Tumbleweed
> > (https://software.opensuse.org/package/maliit-keyboard2) and followed the
> > wiki and the keyboard is still not working.
> 
> The patch hasn't been in Maliit that long, it will take a bit until it
> reaches distro repos. Either wait for that to happen or compile it yourself.

Qtwayland5 and qtwayland5-dev-tools are installed. i still get the error. I've gotten this error every time I've tried to build Maliit since November 2020. Has anyone who continues to recommend Maliit tried to build it themselves on a clean version of KDE Neon user edition or Ubuntu 20.04? There are major problems with building Maliit for KDE Neon user edition. I don't understand how Maliit is being recommended if KDE developers didn't take the time to make sure it could be built properly on popular distributions (like Ubuntu) or on their own distribution (KDE Neon). Why constantly recommend something that doesn't work for the average user?

(In reply to kelnio@yahoo.com from comment #23)
> (In reply to Zamundaaa from comment #22)
> > (In reply to kelnio@yahoo.com from comment #20)
> > > I can't find a qtwaylandscanner package anywhere in the repositories..
> > 
> > qtwaylandscanner is apparently in the package qtwayland5
> > 
> > (In reply to Aitor from comment #21)
> > > I installed maliit in OpenSUSE Tumbleweed
> > > (https://software.opensuse.org/package/maliit-keyboard2) and followed the
> > > wiki and the keyboard is still not working.
> > 
> > The patch hasn't been in Maliit that long, it will take a bit until it
> > reaches distro repos. Either wait for that to happen or compile it yourself.
> 
> Qtwayland5 and qtwayland5-dev-tools are installed. i still get the error.
> I've gotten this error every time I've tried to build Maliit since November
> 2020. Has anyone who continues to recommend Maliit tried to build it
> themselves on a clean version of KDE Neon user edition or Ubuntu 20.04?
> There are major problems with building Maliit for KDE Neon user edition. I
> don't understand how Maliit is being recommended if KDE developers didn't
> take the time to make sure it could be built properly on popular
> distributions (like Ubuntu) or on their own distribution (KDE Neon). Why
> constantly recommend something that doesn't work for the average user?

So I figured out why qtwaylandscanner wasn't being found. Cmake was looking for it in /usr/bin, which is where the qtwayland5-dev package for other distributions like Arch install it. Apparently, KDE Neon/Ubuntu's qtwayland5-dev-tools package installs qtwaylandscanner in /usr/lib/qt5/bin and /usr/lib/x86_64-linux-gnu/qt/bin. I "fixed" the issue by creating a soft link of the file to the /usr/bin directory. However, now I get a new error:

CMake Error at CMakeLists.txt:56 (find_package):
  By not providing "FindQt5XkbCommonSupport.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "Qt5XkbCommonSupport", but CMake did not find one.

  Could not find a package configuration file provided by
  "Qt5XkbCommonSupport" with any of the following names:

    Qt5XkbCommonSupportConfig.cmake
    qt5xkbcommonsupport-config.cmake

  Add the installation prefix of "Qt5XkbCommonSupport" to CMAKE_PREFIX_PATH
  or set "Qt5XkbCommonSupport_DIR" to a directory containing one of the above
  files.  If "Qt5XkbCommonSupport" provides a separate development package or
  SDK, be sure it has been installed.

I've been searching my system, the repositories, and Google for a solution to this new error for the past hour. Honestly, if KDE developers took the time to make sure users could actually build Maliit on at least the most popular distributions like Ubuntu, Arch, or Fedora and provided instructions before recommending Maliit, some of these issues would have been identified. It's very troubling that Maliit won't even build correctly on KDE Neon user edition, a (non) distribution that KDE developers actually have some control over..

QtVirtualKeyboard is no longer used by is because of these problems; we use the Maliit keyboard in the Plasma Wayland session by default.

Please file separate new bug reports for any issues you encounter while using it. Thanks!

I've updated Maliit in neon now to 2.0