Virtual keyboard changes system keyboard layout under sway - why?

[Dorota Czaplejewicz]

Hello Justus,

On Mon, 06 Apr 2020 14:36:03 +0200
Justus-dev at Piater.name wrote:

> Hello,
> 
> In my quest for an on-screen keyboard (OSK) for sway, the closest I've
> found are Purism's squeekboard and virtboard.  They both use the Wayland
> virtual keyboard protocol.  Surprisingly (to me), they affect my
> installed keyboard layout:
> 
> 1. They install a session-wide keyboard layout and leave it behind, at
>    least if terminated improperly.
> 
> 2. Afterwards, I cannot reset my keyboard layout using 'swaymsg input
>    ... xkb_layout de'; it silently runs without taking effect.
>    Running 'swaymsg reload' does restore it though.
> 
> The second phenomenon is surely a defect? In sway, wlroots, or
> {virt|squeek}board? Or is it just that I am trying to abuse Purism's
> OSKs outside their purpose of serving as the only keyboard present on a
> system?
> 
The OSKs are meant to be universal as much as possible, and not tied to any particular system (just Wayland).

> How about the first point? In my naive world view, the OSK should use
> any layout I tell it to use, but it should leave intact the layout of
> any other keyboard I happen to have on my system.  I can attach an
> external keyboard with en_US layout to my laptop with de layout.  Why
> can't I additionally run a French azerty OSK? And yet another Greek
> OSK at the same time?
> 
My understanding of how layouts work on Linux is a bit different than what you present here. I've observed that there is a global layout switch, and with multiple physical keyboards, I found that switching the layout affects all of them. Therefore, to make the on-screen keyboard work "as expected", I decided to make it follow that central authority (gnome input method setting).

Following the central authority only works well when it's done consistently, so I tied the keyboard language switch back to the system layout. This is simpler than having a different global layout and a different layout for a single keyboard, and hopefully spares users confusion (e.g. "I selected de in the system settings but my keyboard is still ru").

Frankly, what you're saying sounds sensible, but I don't know how to solve it on the application level without making things overly complicated. If you do, then the best channel to discuss that would be the Squeekboard issue tracker: https://source.puri.sm/Librem5/squeekboard/issues/

> I clearly lack understanding of how Wayland input protocols work, and
> hope someone over here will enlighten me.  In particular, is the
> behavior I describe above intentional or accidental?
> 
> My motivation is that I am trying to understand what it minimally takes
> to inject characters into applications under Wayland (specifically
> sway).  For example, for my touchscreen I would like to have an OSK and
> dasher [1].  For my scripted password manager, formerly based on
> xdotool, I wrote uinputchars [2], which works perfectly for me but is
> only a crutch until I have a proper Wayland solution.
> 
The solutions are the virtual-keyboard protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/11
and the input-method protocol https://source.puri.sm/Librem5/squeekboard/blob/master/protocols/input-method-unstable-v2.xml
which depends on the text-input protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/19

Best,
Dorota

> Thanks,
> Justus
> 
> 
> [1] https://github.com/dasher-project/dasher
> [2] https://github.com/piater/uinputchars
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200406/e32b3ffa/attachment.sig>