Draft: Revisit a situation regarding the input methods in lockscreen

Bit of history

Back in commit a355bca0, as a workaround(?) to the bug 306932 it was suggested by the @hein to allow simply set the QT_IM_MODULE to compose key. Which worked fine for X11, now after we started using maliit keyboard for Plasma Mobile (old maliit and not new one), I changed that to allow the maliit as QT_IM_MODULE when using lockscreen greeter in the commit 44afdad7.

After that plasma-workspace@b6705f8d, enabled using qtvirtualkeyboard for the lockscreen, condition was changed to explicitly set QT_IM_MODULE to qtvirtualkeyboard instead of compose previously in the commit c23f5322.

Current situation

kwin@7aabd45d added support for the input-method-unstable-v1 in KWin wayland, which means that the we got support for the proper wayland input methods, and can use the maliit2 instead of old dbus method.

This requires that client does not have any QT_IM_MODULE set on it however, which means QT_IM_MODULE=maliit condition here is set to wrong, and that means it will try to set QT_IM_MODULE to maliit. Applying the patch I have here it makes it "work" with the recent kwin wayland and I can enter my password using the maliit, but this introduces several regressions and introduces the original bug we had back.

• Lockscreen Virtual Keyboard stops working on X11
• If input method is not configured (i.e --input-method maliit-keyboard is not passed to the kwin_wayland) then we end up with no virtual keyboard in the Lockscreen.

I am not sure what is correct solution here, but that said, current solution of setting QT_IM_MODULE to qtvirtualkeyboard by default is also "wrong" because that stops compose key from working and if your password have characters which requires compose key, well Good luck.

Ideally on wayland solution I have mind is to not set this environment variable at all if there is input-method registered with compositor (kwin_wayland). But currently the client (kscreenlocker_greet) have no way of knowing that from compositor using wayland APIs. But then X11 situation is also not so well here IMO.

I have opened this merge request as a point of discussion, please do not merge this as-is.