With respect to touch input, most parts of KDE can be handled very easily. However, one, imho, very important aspect, simply lacks all touch UI support: the lock screen (and also the login screen), right now, do not support touch UIs at all.
There is a somewhat recent bug report that requests the addition of virtual keyboard support to the lock screen but so far it seems that no solution is available yet. Personally, I was very surprised that such an, imho, important feature like a “proper” touch UI lock screen, is not available in KDE. Even the touch-optimized plasma-mobile/Plasma Active doesn’t offer a proper touch UI lock screen. With “proper” I mean a lock screen that really offers security features.
I played a little around and could at least get a KDE lock screen that shows an on-screen keyboard. My approach was to use Maliit in combination with the stock KDE lock screen. I am using Fedora as Linux distribution and installed Maliit as follows:
yum install maliit-plugins maliit-framework-qt4
The next step is to start the lock screen with Maliit as input method. This can be done manually as follows:
QT_IM_MODULE=Maliit /usr/libexec/kde4/kscreenlocker_greet
Once the lock screen is shown, clicking in the input field opens the Maliit on-screen keyboard. Note that this only works when run for the first time, when the maliit-server is started when the input field is clicked. Subsequent attempts on using this command line do not show the Maliit keyboard on the lock screen. Reason is that the lock screen is implemented such that it covers all other windows, including the virtual keyboard. The fact that the keyboard is shown on the first run may be a bug in the lock screen but I am not sure about this.
The fact that the on-screen keyboard is shown on the first invocation already gives a hint for a temporary solution. Killing all maliit-server processes before using above command line fixes the observed issue.
Right now, I use this hack as workaround. I created a shell script for killing maliit-server and starting /usr/libexec/kde4/kscreenlocker_greet. Then, I added a quick launch widget to my desktop for running the script. So, the result for me is that I can finally lock the KDE desktop and unlock it via an virtual on-screen keyboard.
This is quite a hack. I am event not sure how long this will work, assumed that the “workaround” presented here may be, in fact, (partly) a bug. However, I think, this hack already shows one possible solution. The only thing that needs to be done is to allow to display Maliit keyboards on the lock screen; allow to show the Maliit virtual keyboard window above of the lock screen.
Furthermore, I experimented with replacing the kscreenlocker_greet binary with a shell script. I moved kscreenlocker_greet to kscreenlocker_greet_bin and created a shell script named kscreenlocker_greet which calls the renamed binary with QT_IM_MALIIT being set. This way, all the built-in lock actions make use of this new approach. Unfortunately, when being called this way, the Maliit keyboard is shown underneath the lock screen; i.e., after unlocking via the normal keyboard, the Maliit on-screen keyboard is visible. As far as I understand, this is the intended way of how kscreenlocker should work and is a security feature; no other application are allowed to be shown on top of the lock screen. However, if it would be great if there was a way to define an exception to that such that the Maliit keyboard can be displayed in the lock screen. Then this whole issue could simply be solved by using the Maliit input method for the lock screen executable.
Maybe, a similar solution could be used to enable an on-screen keyboard for KDM. However, I didn’t look that much into this right now.
ruedigergad 
I thought this could be done with plasma already. There should already exist a Plasma virtual keyboard somewhere. And the screen locker/KDM has been able to run Plasma widgets for some time if blog post from 1-2 years back are accurate(Have not tested it). White-listing the Plasma OSC and putting it on the lock screen should work.
Yes, there is a virtual keyboard widget. Unfortunately, this keyboard widget only works properly when added to the launcher; it does not work when added to the desktop.
I assume you are referring to the lock screen variant which enables adding widgets. Unfortunately, this variant only allows desktop widgets. Hence, the virtual keyboard widget does not work.
The problem is that the keyboard “steals” the focus from the input field once a key is presses, so it is impossible to enter the password this way. Consequently, another workaround would be to “fix” this behavior and prohibit the keyboard widget from stealing the focus. However, there is a little older bug report about this which, essentially, states that this won’t or even can’t be fixed. I don’t remember the exact bug report URL right now but could look it up if you are interested in it.
PS: If you happen to have links about this it would be great if you could share them. I am still looking for a better solution. 🙂
> The fact that the keyboard is shown on the first run may be a bug in the lock screen
yes, that’s a bug. Nothing should be shown above the lock screen.
Thanks for the information. Is there an easy way to “whitelist” the on-screen keyboard?
This falls into the same category of issue that KWin needs to be able to know about the on screen keyboard (OSK) so it can handle the exceptions to security requirements such as this.
We need a way for KWin (or any system compositor) to identify the OSK window. This likely means that the compositor needs to launch and then ‘bless’ the OSK process. This is the model Wayland uses, so should also be an important part of the path forward there.
while you are right, I need to do a small correction for the X11 world: the screenlocker needs to know the OSK – KWin doesn’t matter in that case.
Still having KWin know the OSK could improve lots