The virtual keyboard stopped working for me in Wayland on my Surface Pro 4 with the release of 5.20.0. No matter what I do, it will not launch for ANY application, to include QT applications. I mentioned that it was not working in the KDE Plasma and KDE Neon sites on Telegram, and I create several post about it on KDE's Reddit page. I even added my two cents to some of the bugs reported on the issue. I have yet to receive any feedback from developers on the subject.

Has the virtual keyboard been removed? I heard from someone who posted a "fix" to get qtvkd working under Wayland that the official virtual keyboard (qtvirtualkeyboard) was no longer being supported in favor of "external virtual keyboards." (https://forum.manjaro.org/t/tip-how-to- ... land/34275) This makes absolutely no sense to me as, based on my understanding, Wayland doesn't allow for external virtual keyboards.

What is going on with the virtual keyboard in Wayland? I've waited through 4 releases of 5.20, and the virtual keyboard is still not fixed. Has it been removed by the KDE team, and what do you suggest we replace it with? I can't use Plasma Wayland on my tablet without a darn working virtual keyboard!!!

to get the full picture, a link to said bug reports might be helpful...

Hi!

Wayland is a different approach than the XServer is/was. There are possibilities to force applications to run in X-compat-mode or wayland if one wants to. As you don't tell us about your operating system, Qt and Plasma-versions, the things you've tried so far and the exact (error-) messages you got, you're on your own.
As an example, you can start e.g. the Kontact suite in xwayland compatibility mode with

Code: Select all

kontact --platform xcb

See using-qt-virtual-keyboard-with-qt-wayland for details about how doing this with the virtual keyboard.

koffeinfriedhof wrote:Hi!

Wayland is a different approach than the XServer is/was. There are possibilities to force applications to run in X-compat-mode or wayland if one wants to. As you don't tell us about your operating system, Qt and Plasma-versions, the things you've tried so far and the exact (error-) messages you got, you're on your own.
As an example, you can start e.g. the Kontact suite in xwayland compatibility mode with

Code: Select all

kontact --platform xcb

See using-qt-virtual-keyboard-with-qt-wayland for details about how doing this with the virtual keyboard.

I apologize. I'm currently running:

Manjaro (KDE)
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2
Kernel Version: 5.10.1-arch1-1-surface

On a Surface Pro 4 with:
Processor: Intel Core i5-6300U CPU @ 2.40GHz
Memory: 15.6 GiB of RAM
Graphics Processor: Mesa Intel HD Graphics 520 (2736x1824 (3:2) HiDPI display)

I don't get any error messages. I do get the "On-Screen Keyboard Activated" dialog when I disconnect my Surface Keyboard Typecover. However, the keyboard does not come up at all with any application, to include KDE Plasma default applications. Again, I don't get any error messages.

I started experiencing virtual keyboard issues with Manjaro KDE Plasma Version 5.18.5, about 5 months ago. The keyboard was stuck at the top of the screen for the SDDM login screen and lock screen (https://www.reddit.com/r/kde/comments/h ... njaro_kde/). I switched to KDE Neon shortly afterwards, and started having the same issue with the 5.19 cycle. I thought 5.20 would fix it, but it didn't. I finally had enough and submitted a bug report when 5.20.1 came out (https://bugs.kde.org/show_bug.cgi?id=428091).

The virtual keyboard stopped working in the Wayland session completely when 5.20 was released. Here is the bug report on it (https://bugs.kde.org/show_bug.cgi?id=427972).

Wait.... looks like an explanation was finally posted yesterday on the bug report! Yeah!! Only took two months for someone to finally acknowledge that this was a problem!!

I apologize if I seem a little testy, but this has been the least transparent thing I have experienced with KDE Plasma. I've asked why the virtual keyboard was pinned to the top of the screen for SDDM and the lock screen directly in the KDE Plasma channel on Telegram, on the Manjaro reddit page, in the Manjaro forum, and finally submitted a bug report for the issue when I switched to Neon. I got no resolution or explanation.

Then the virtual keyboard is broken completely for the Plasma Wayland session in 5.20. Again, I asked what was going on in Telegram (where I received no answer), then went to submit a bug report only to see one was already there. Ten days after the bug report was released, still nothing. Then I started hearing (from other users) that virtual keyboard support was altered with 5.20. I asked again what was going on in the bug report, on Telegram, on Reddit, on Nate's weekly blog (several times), and finally here. Finally, after over two months of getting no answers, we learn that virtual keyboard support was indeed changed for 5.20, but there is no viable solution at this time.

You folks have been a lot more transparent in the past....

Okay. Let me know if the maliit works with plasma

/edit:
If you need support just in time, you should buy it. A lot of work is done by volunteers in their spare time, so we often have to wait until a developer spends his lifetime to solve our problems without getting paid for it.

koffeinfriedhof wrote:Okay. Let me know if the maliit works with plasma

I installed the maliit-keyboard on Manjaro from the AUR last night. I ran it from a terminal (in a KDE Plasma Wayland session), got a lot of output with no errors, but the keyboard didn't show. I couldn't figure out a way to get it to show with any apps (or show at all), so I gave up.

I'm reading the comments on the subject at invent.kde.org (https://invent.kde.org/plasma/kwin/-/merge_requests/565). This comment from Nate Graham hit the nail on the head for me:

"I agree, these aren't seen by the user as apps, so I wouldn't put the UI in the default applications KCM.
A system tray item to open the virtual keyboard is something I've wanted for a while. Last night I was using my convertible laptop as a tablet and everything was perfect except for the lack of a way to display a virtual keyboard.
If the input method were made selectable in a tray applet, I would want it to be a separate one from the (proposed) one that shows and hides the virtual keyboard, so you can still show and hide it with one tap.
But ultimately I think it would be best if we could make all of these input methods co-exist so that the user doesn't have to pick one manually."

Wayland has been recommended for tablets, and for HiDPI displays. My Surface Pro 4 checks both boxes because it is a tablet with HiDPI display. However, the Plasma Wayland session was buggy and almost completely unusable until the team put some effort into it at the end of the 5.19 cycle. Unfortunately, when 5.20 finally made Plasma Wayland a viable replacement for the Xorg session on my tablet, we get a large kick in the gut from the virtual keyboard being broken. Talk about terrible, terrible, TERRIBLE timing!

As Nate mentioned, Plasma Wayland would be perfect on tablets if the virtual keyboard was working and there was a way to display it. IMO we need a tray icon and the ability to have a floating keyboard icon, just like what Onboard has (which I am using with the Plasma Xorg session).

Well, its open source. You could help making Wayland integration better instead of complaining. Spend your free time in development of a virtual keyboard and everyone is happy.

koffeinfriedhof wrote:Well, its open source. You could help making Wayland integration better instead of complaining. Spend your free time in development of a virtual keyboard and everyone is happy.

So, every time something gets broken and a user ask why, they should just fix it themselves because it is open source? That's a cop-out! I have the upmost respect for developers. However, I'm not a developer, I don't have time to be one, and I don't want to be one. I've used Linux as my primary desktop OS for over 23 years (KDE since version 1). I've contributed by submitting bug reports, testing software, donating to my favorite distribution, and helping out wherever I can. You can't expect every Linux user to be a developer or even want to be a developer.

The only thing I'm asking for is a little more transparency. If there is going to be another major change like this in the future, please let us users know so we can make adjustments accordingly.

No, I cannot fix that myself, I think. But I don't share the expectations you have. Wayland-Support is quite new in Plasma (since 2019) and is far from being a complete replace for X; it is something different and there is a lot of work to do for environments that are used to follow the XServer standards. A native Wayland operating system like e.g. Sailfish OS works, including virtual keyboards, as it has not to respect all the X-stuff. As shown in the bug-report you linked, the workaround using Qtvkbd is forcing Qt under Wayland to use the X-compatibility which will not work properly. As explained by Nicolas Fella the QtVirtualKeyboard was replaced and it works under Wayland if you force KWin on startup to use it, like they do on Plasma mobile.

To follow up with changes, you can read mailing lists or the monthly summaries, e.g. https://kde.org/announcements/plasma-5.20.3-5.20.4-changelog/ or since it was a really big release look at the full Plasma 5.20.0 changelog.

Concerning your problem: The AUR is for arch users, not Manjaro. So it can work, but it does not have to as Manjaro does things differently. Then, the only thing I could find i https://aur.archlinux.org/packages/maliit-framework-git/ which was last updated in 2015 and only provides the framework, not the keyboard.
So what exactly did you try?

Correction, the maliit-keyboard is in the official Manjaro repository and not the AUR. I was confused because the package is called "maliit-keyboard-git' ...git files are normally in the AUR. It was compiled on 11/27/2020. I installed it, but couldn't figure out how to get it to work with Plasma Wayland or Plasma Xorg (or at all).

I think you're confusing my frustration with the lack of communication and transparency on the virtual keyboard as an overall frustration with Plasma Wayland. While I will admit that I am frustrated with Wayland in general, I believe that the KDE Plasma team has done a great job so far with Plasma Wayland for the 5.20 cycle. My sole focus with this thread was to figure out why the virtual keyboard was broken for Plasma Wayland beginning with 5.20, why it was not being fully acknowledge as broken (bug reports and direct request for information were being ignored), and what was being done to fix it.

I've never had an issue in the past with the KDE team not being straight with me or the community, even if we didn't like the answer... so this whole ordeal has been a little jarring.

No problem. I know that sometimes things are frustrating. As I try to code myself in my spare time, I just learned that some things are really hard to achieve. On one computer it runs flawlessly, on the other it just does not work as expected.

I just found two packages on https://mirror.netcologne.de/manjaro/pool/overlay/. They are also splitted in framework (with the server package) and the keyboard plugin, if you installed the keyboard-package it should have installed the framework too, as it is a dependency in the .PKGINFO.

Does the `maliit-server` generate some output if started manually? Does `maliit-exampleapp-plainqt` work? Both are part of the framwork-package. In the meantime, I try to use the maliit-stuff in a virtual machine to better understand it.

I've setup Manjaro with plasma-wayland support (switching to the whole plasma/framework/wayland/-git versions) and installed maliit-{framework,keyboard}-git. It didn't work as expected. Trying to compile it from source, I saw that it is not well documented and there were some missing parts in the CMakeLists.txt to compile it in Manjaro. I played around with some settings, but it did just not work and QT_IM_MODULE=Maliit never led to a virtual keyboard.

But the default qvirtualkeyboard is working in the wayland-session if you use it like in this Kate example:

Code: Select all

QT_XCB_GL_INTEGRATION=xcb_egl QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=xcomposite-egl QT_IM_MODULE=qtvirtualkeyboard kate --platform xcb


which basically just uses the x-compatibility to make it work. Perhaps you can use this environment variables approach until a working solution is available upstream?

As I don't know how the signals are handled while detaching the keyboard / switching to «tablet mode», I cannot test it further. I think there will be a UDEV-trigger be called. Perhaps you can hook to that.
Manjaro is really different from arch as I found out while testing (including an annoying mouse-position-bug). Didn't expect that much changes. Well, now I know it is true that Manjaro is not arch

https://bugs.kde.org/show_bug.cgi?id=440467

I opened this bug. See if it fits your problem