can not show up input interface on arch linux sway wm

[alvin998179]

Can not show up input interface on arch linux sway wm. No input method list in configure interface. Is it include any wubi table?

[stvhuang]

I meet the same issue, in Sway, the candidate window shows up only in XWayland apps but not native Wayland.

[zhangn1985]

vote +1

[wengxt]

I don't know what do you expect, but if the app doesn't run with wayland + wayland input method, you'll not able to see input method.

Because the application you run is using dbus to talk to fcitx, and there is no way to place the input window correctly.

[zhangn1985]

so the improvment should be done at sway side? how?

or use different way to start fcitx in sway?

[wengxt]

One thing is swaywm/sway#3407

The other is the application need to use wayland text input protocol to type text, which is even nowadays, not widely supported.

In conclusion, input method on wayland is almost impossible to work properly because of lacking support. Also an old blog post FYI: https://www.csslayer.info/wordpress/fcitx-dev/the-road-to-fcitx-5-3-you-can-not-type-on-wayland-properly/

[hexchain]

One thing is swaywm/sway#3407

The other is the application need to use wayland text input protocol to type text, which is even nowadays, not widely supported.

With fcitx 4, I was able to see the candidate list when typing in either Wayland or Xwayland application, although it seems to be an Xwayland window, and the position is not always correct (probably due to my 2x HiDPI scaling? I'm not sure).

Can something similar be achieved with fcitx 5?

[pickfire]

swaywm/sway#4740

Sway supports input method now.

[wengxt]

but you still need application to use the wayland protocol.

[pickfire]

Looks like the library used by alacritty does not support wayland input method yet.

rust-windowing/winit#952

[wengxt]

Wayland protocol is a little bit messy there, there seems to be a inputmethod v2 some where, but it's not inclulded in wayland-protocols package.. not sure about the authority there.

So FYI first, compositor <-> application is using text_input (v1 v2 v3...), there can be mix and match, just depending on the compositor implementation.
compositor <-> input method is using input method (v1 v2). v1 is included in wayland-protocols. There is also input method v2. From the copyright we can learn that it's contributed by prism Inc (a linux phone/pc company), but fcitx don't support that yet (not ibus too).

Just FYI, sway is using the v2. so fcitx can't yet work with it. Also since v2 remove the input panel positioning part, we don't yet know where to move the input method window with this protocol.

[pickfire]

I believe it is using text input v3 and input method v2 (https://github.com/swaywm/sway/pull/4740/files#diff-eae6d3dc662e1c89d86c0feb69226b96R4). The protocols are in https://github.com/wayland-project/wayland-protocols/blob/b0a25f26d3e8b5ad24773881a9a895dd9cc75466/Makefile.am#L9, they only have input method v1 but wlroots have input method v2 https://github.com/swaywm/wlroots/blob/master/protocol/input-method-unstable-v2.xml, looks like wlroots in leading wayland input method development?

[wengxt]

I won't say "leading" but "lack of cooperation".

What is the point to use a protocol when no one support it?

[pickfire]

What is the point to use a protocol when no one support it?

I believe that is because people are happy with X11 so there are less motivation to move to wayland. Probably similar to what happened to xcb as xlib already works even though I heard xcb is more efficient.

[wengxt]

No, the protocol that I refer to is input method v2. It’s not accepted in wayland-protocols, so lots of people don’t even know about it. I saw it on wl list 2 years ago and I assume no merge means rejected. Now it comes from nowhere? wlroot has the “authority”(or only copy) version of the xml protocol? that sounds like a joke to me because it’s a library. there ought to be somewhere solely for maintaining protocol file. who is gonna maintaining the latest protocol? Do I need to just randomly copy the protocol? (wlroot sounds like a random place on the internet to me) As you can see, they(sway) can’t even have a good test on their implementation.

…

On Wed, May 20, 2020 at 09:14 Ivan Tham ***@***.***> wrote: What is the point to use a protocol when no one support it? I believe that is because people are happy with X11 so there are less motivation to move to wayland. Probably similar to what happened to xcb as xlib already works even though I heard xcb is more efficient. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7MZAY3ZYPKHTENCMBNFTRSP6XJANCNFSM4LB5CBTA> .

[cathay4t]

The fcitx5 0.0.0.20200817-1 and sway 1:1.5-1 works well on firefox(MOZ_ENABLE_WAYLAND=1) including input interface and positioning.
The alacritty still cannot works with fcitx, but that does not bother me.

Thanks for the magic work!

[wengxt]

I doubt the positioning would work. but as long as firefox is the only window and takes all the screen, the positioning might just accidentally works. Just FYI

[pickfire]

The alacritty still cannot works with fcitx, but that does not bother me.

Alacritty and fcitx works well on X11, not sure about Wayland.

[cathay4t]

I doubt the positioning would work. but as long as firefox is the only window and takes all the screen, the positioning might just accidentally works. Just FYI

When firefox is at the sway output holding position 0 0, the fcitx input box looks good: https://fedorapeople.org/~cathay4t/tmp/fcitx5_wayland_screen_shot.png

[zhangn1985]

@cathay4t do you have wikipage for how to config fcitx5 work on sway?

[cathay4t]

@zhangn1985 No I don't.

I just export these variables before starting sway:

export MOZ_ENABLE_WAYLAND=1
export XDG_SESSION_TYPE=wayland
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"

And then exec --no-startup-id fcitx5 -d in sway config and enable wayland in fcitx5-configtool.

[AndreaOrru]

@zhangn1985 No I don't.

I just export these variables before starting sway:

export MOZ_ENABLE_WAYLAND=1
export XDG_SESSION_TYPE=wayland
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"

And then exec --no-startup-id fcitx5 -d in sway config and enable wayland in fcitx5-configtool.

I'm using the latest git revision of Sway and Fcitx5 with your exact same configuration but the positioning is still wrong. If I leave only Wayland enabled and disable the other frontends in Fcitx5, no popup is shown.

Any ideas? I don't think Firefox implements wayland-input... Are you 100% sure you're running Firefox in Wayland mode?

[wengxt]

@AndreaOrru GTK_IM_MODULE need to be wayland I think to make firefox use wayland im protocol. Otherwise you'll need to use X wayland to display UI. But sway's support for wayland im protocol is not complete, which make it impossible to use the actual wayland ui for im.

[fpemud]

Why GTK not auto detect it is using wayland backend and then use wayland im protocol as its default?

[wengxt]

I added client side ui for wayland + qt im module, now qt application should be able to display the input panel.

[wengxt]

Now Gtk also supports the client side ui thing: fcitx/fcitx5-gtk@2151050

[cathay4t]

@zhangn1985 No I don't.
I just export these variables before starting sway:

export MOZ_ENABLE_WAYLAND=1
export XDG_SESSION_TYPE=wayland
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"

And then exec --no-startup-id fcitx5 -d in sway config and enable wayland in fcitx5-configtool.

I'm using the latest git revision of Sway and Fcitx5 with your exact same configuration but the positioning is still wrong. If I leave only Wayland enabled and disable the other frontends in Fcitx5, no popup is shown.

Any ideas? I don't think Firefox implements wayland-input... Are you 100% sure you're running Firefox in Wayland mode?

The swaymsg -t get_tree shows "app_id": "firefox" which indicate firefox is in wayland mode.
And below command shows firefix is using dbus interface of fcitx:

[fge@Gris-Laptop ~]$ qdbus6  org.fcitx.Fcitx5 /controller org.fcitx.Fcitx.Controller1.DebugInfo
Group [wayland:] has 5 InputContext(s)
  IC [f638583b8ec74af6a28ac185edc570a9] program:firefox frontend:dbus cap:e001000012 focus:0
  IC [c6f8871734d04bd58935d03e7a829bfe] program:firefox frontend:dbus cap:e001000012 focus:0
  IC [f88b5eb88a6f4464a547415e9efe12d9] program:firefox frontend:dbus cap:e001000012 focus:0
  IC [28f8f361a28d485cb5e0ed5535ed0cbc] program:firefox frontend:dbus cap:e001000052 focus:0
  IC [07e4250a95464b7d910788f66632c9f2] program: frontend:wayland_v2 cap:0 focus:1
Group [x11::0] has 0 InputContext(s)
Input Context without group

While alacritty is using native wayland_v2, which can not show the input interface for now(fcitx5 5.0.8-1 archlinux).

[cathay4t]

In my environment, using GTK_IM_MODULE=wayland will cause firefox lose fcitx input candidate interface, so I still use
GTK_IM_MODULE=fcitx. Just FYI.

All my environment variables of sway are https://gist.github.com/cathay4t/fe230538a218528dc7f8594a7a6d01e4

[wengxt]

@cathay4t while sway support "text-input-v3 + zwp_input_method_v2", it doesn't support input panel protocol, thus no UI is available. It does not make sense to draw a X11 for a native wayland window because positioning could not be done properly. Maybe you can just run alacritty with X11 if you still want to use alacritty.

[cathay4t]

@wengxt Thanks for the detail. I noticed the efforts are ongoing at swaywm/sway#5890 Great work!