Works for me with maliit-keyboard on Wayland; it does requite Wayland, not X11. Are you using X11?

(In reply to Nate Graham from comment #1)
> Works for me with maliit-keyboard on Wayland; it does requite Wayland, not
> X11. Are you using X11?

Definitely using wayland, with the sole exception of the surface-kernel it's a default install of fedora. Another surface-kernel user running Debian reported the same issue. 

No matter what I do I am unable to get Maliit to open, IT IS running in the background, but whatever event is supposed to trigger it, like selecting a text entry field has no result.

Is there a report I can run to provide more information, help get this fixed? Right now the solution in the surface-linux chat is install gnome...

I don't know, sorry. Someone who understands more about how Maliit and KWin interact will have to debug further.

```
bool InputMethod::shouldShowOnActive() const
{
    return input()->touch() == input()->lastInputHandler()
        || input()->tablet() == input()->lastInputHandler();
}
```

This is the block of code in kwin which decides to show the keyboard, if the previous event was a touch or tablet event, as opposed to something being focused by default or via mouse click. If it's not working on your device, it seems possible that the touch panel driver for it is not correctly sending the events. I do not have any Surface devices, and so cannot test them with that kernel.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2527

(In reply to Rodney Dawes from comment #4)
> ```
> bool InputMethod::shouldShowOnActive() const
> {
>     return input()->touch() == input()->lastInputHandler()
>         || input()->tablet() == input()->lastInputHandler();
> }
> ```
> 
> This is the block of code in kwin which decides to show the keyboard, if the
> previous event was a touch or tablet event, as opposed to something being
> focused by default or via mouse click. If it's not working on your device,
> it seems possible that the touch panel driver for it is not correctly
> sending the events. I do not have any Surface devices, and so cannot test
> them with that kernel.

Well, to get the touch screen working on my surface pro 6 in addition to the surface-kernel  you need iptsd enabled and libwacom-surface installed. I'm wondering if kwin isn't recognizing the touch input because it's using the wacom driver? Maliit still won't activate and I've fully updated the all the software. I would love to find a way to get this working, the "solution" in the linux-surface community is to install Gnome... Kinda defeats why I chose KDE...

You can learn a bit more about the events that you are getting using "sudo libinput debug-events".

It shouldn't matter much where it's coming from as it's all fed by libinput (supposedly, that is). My external wacom tablet does feed proper touch events.

(In reply to Aleix Pol from comment #7)
> You can learn a bit more about the events that you are getting using "sudo
> libinput debug-events".
> 
> It shouldn't matter much where it's coming from as it's all fed by libinput
> (supposedly, that is). My external wacom tablet does feed proper touch
> events.

 -event19  DEVICE_ADDED            Video Bus                         seat0 default group1  cap:k
-event0   DEVICE_ADDED            Lid Switch                        seat0 default group2  cap:S
-event3   DEVICE_ADDED            Microsoft Surface Type Cover Consumer Control seat0 default group3  cap:kp scroll-nat
-event5   DEVICE_ADDED            Microsoft Surface Type Cover Touchpad seat0 default group3  cap:pg  size 98x50mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on dwtp-on
-event12  DEVICE_ADDED            Microsoft Surface Type Cover Tablet Mode Switch seat0 default group3  cap:S
-event1   DEVICE_ADDED            Microsoft Surface Type Cover Keyboard seat0 default group3  cap:k
-event2   DEVICE_ADDED            Microsoft Surface Type Cover Mouse seat0 default group3  cap:p left scroll-nat scroll-button
-event21  DEVICE_ADDED            gpio-keys                         seat0 default group4  cap:k
-event22  DEVICE_ADDED            gpio-keys                         seat0 default group4  cap:k
-event30  DEVICE_ADDED            IPTS Touch                        seat0 default group5  cap:t  size 259x171mm ntouches 11 calib
-event31  DEVICE_ADDED            IPTS Stylus                       seat0 default group6  cap:T  size 259x171mm calib
-event1   DEVICE_REMOVED          Microsoft Surface Type Cover Keyboard seat0 default group3  cap:k
-event2   DEVICE_REMOVED          Microsoft Surface Type Cover Mouse seat0 default group3  cap:p
-event3   DEVICE_REMOVED          Microsoft Surface Type Cover Consumer Control seat0 default group3  cap:kp
-event5   DEVICE_REMOVED          Microsoft Surface Type Cover Touchpad seat0 default group3  cap:pg  size 98x50mm
-event12  DEVICE_REMOVED          Microsoft Surface Type Cover Tablet Mode Switch seat0 default group3  cap:S
-event30  TOUCH_DOWN              +3.479s       0 (0)  0.98/98.76 ( 2.54/169.33mm)
 event30  TOUCH_FRAME             +3.479s
 event30  TOUCH_MOTION            +3.490s       0 (0)  0.97/98.76 ( 2.51/169.33mm)
 event30  TOUCH_FRAME             +3.490s
 event30  TOUCH_MOTION            +3.500s       0 (0)  0.83/98.78 ( 2.16/169.36mm)
 event30  TOUCH_FRAME             +3.500s
 event30  TOUCH_UP                +3.511s       0 (0)
 event30  TOUCH_FRAME             +3.511s
 event30  TOUCH_DOWN              +5.871s       0 (0) 22.06/41.40 (57.24/70.98mm)
 event30  TOUCH_FRAME             +5.871s
 event30  TOUCH_UP                +5.892s       0 (0)
 event30  TOUCH_FRAME             +5.892s
 event30  TOUCH_DOWN              +14.083s      0 (0) 22.62/41.06 (58.70/70.40mm)
 event30  TOUCH_FRAME             +14.083s
 event30  TOUCH_MOTION            +14.083s      0 (0) 22.69/41.08 (58.86/70.43mm)
 event30  TOUCH_FRAME             +14.083s
 event30  TOUCH_MOTION            +14.085s      0 (0) 22.63/41.17 (58.73/70.60mm)
 event30  TOUCH_FRAME             +14.085s
 event30  TOUCH_UP                +14.085s      0 (0)
 event30  TOUCH_FRAME             +14.085s
-event3   DEVICE_ADDED            Microsoft Surface Type Cover Consumer Control seat0 default group7  cap:kp scroll-nat
-event12  DEVICE_ADDED            Microsoft Surface Type Cover Tablet Mode Switch seat0 default group7  cap:S
-event1   DEVICE_ADDED            Microsoft Surface Type Cover Keyboard seat0 default group7  cap:k
-event2   DEVICE_ADDED            Microsoft Surface Type Cover Mouse seat0 default group7  cap:p left scroll-nat scroll-button
-event5   DEVICE_ADDED            Microsoft Surface Type Cover Touchpad seat0 default group7  cap:pg  size 98x50mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on dwtp-on
-event12  SWITCH_TOGGLE           +23.371s      switch tablet-mode state 1
 event12  SWITCH_TOGGLE           +23.472s      switch tablet-mode state 0

Does it only happen when you are detached or non-detached?

I see that the touch events are properly issued and so is the "detached switch" thing at the bottom.

(In reply to Aleix Pol from comment #9)
> Does it only happen when you are detached or non-detached?
> 
> I see that the touch events are properly issued and so is the "detached
> switch" thing at the bottom.

Okay, so basically I can't get the onscreen keyboard to come up on the screen no matter what. 

Keyboard attached or detached, doesn't matter. Even manually toggling the onscreen keyboard on in the gui does nothing.

I've discussed with the maliit dev, they helped me confirm that the keyboard itself is running in the background, but nothing i do as a user will trigger it.

So I'm in a similar boat.
Fedora 36 (wayland + KWIN used)
KDE Plasma 5.25.2
Framework 5.94
QT version 5.15.3

I find it amazing that no-one from KDE seems to care that an accessibility requirement like a virtual keyboard is not working.

Alex - could you try checking your environment variables on a "konsole" (type the following - without quotes - "set |grep MODULE").
Also, on that same window, try typing (again no quotes): "QT_IM_MODULE=qtvirtualkeyboard kwrite"

On mine, I get an error message and the "maliit" keyboard flashes up.
The error is: "qt.qpa.wayland: qtvirtualkeyboard currently is not supported at client-side, use QT_IM_MODULE=qtvirtualkeyboard at compositor-side."

I suspect that because "ibus" is set then the virtual keyboard isn't appearing.....
Which is silly isn't it? ibus is purposely built to use an input method mechanism, while force-setting it to ONLY virtualkeyboard is wrong for things where you can plug in keyboards, or 2-in-1 laptops where the keyboard folds away.
Even worse - where can I set the IM module variable on the compositor-side? do I have to manually edit the "kwinrc" file? Other files?

I will try to take this further myself, but why is the virtual keyboard not showing in ALL situations where it's enabled!? This is just bad user experience!

Created attachment 150527 [details]
maliit selected

QT_IM_MODULE should be unset at all times. Make sure that you have maliit selected in the Virtual Keyboard KCM.

I see you mentioned you're running Fedora, there's some mechanisms there to inject some environment variables that override Plasma's default settings to make it accessible to ibus and would break maliit usage. Please reach out to them to address this,

For reference: https://pagure.io/fedora-kde/SIG/issue/220

(In reply to Aleix Pol from comment #13)
> QT_IM_MODULE should be unset at all times. Make sure that you have maliit
> selected in the Virtual Keyboard KCM.
> 
> I see you mentioned you're running Fedora, there's some mechanisms there to
> inject some environment variables that override Plasma's default settings to
> make it accessible to ibus and would break maliit usage. Please reach out to
> them to address this,
> 
> For reference: https://pagure.io/fedora-kde/SIG/issue/220

Thanks Aleix.
I did unset the variable last night and found it worked.
imsetting + ibus are the 2 offending pieces which are causing these variables to be set.
I thought I read last night how the qtvirtualkeyboard was using the "imsettings-qt" plugin/library, but cannot find it again today.

Alexander - please try and check your environment variables, as this may be the root cause.

I am currently testing out the following solution:
1) Copy "ibus.conf" to a new file "QT.conf" in /etc/X11/xinit/xinput.d/
    - change it slightly to set QT_IM_MODULE="" and description to "QT".
    - use "imsetting-switch QT" to set it to your new QT setup
2) edit ~/.config/environment.d/imsettings-qt.conf and set "QT_IM_MODULE="
3) reboot the laptop (I think the imsettings are set when sddm starts up in systemd, and inherited by KDE - which then makes the config in the user's home dir or overrides them with the values from the same config file if it exists.

I'm still testing to see if anything has broken by removing ibus from the input method.

If distros override QT_IM_MODULE, there's not much we can do.