[Wayland] Candidate list for Fcitx5 immediately disappears/flickers in fullscreen windows (text-input-v3)

[layercak3]

SDL main 6187edd41e318f9c434ba178fb32a8ef2b07e5da (issue also present in 2.0.22) Latest sway from master branch + https://github.com/swaywm/sway/pull/5890 Latest wlroots from master branch

I am using Fcitx5 for non-Latin alphabet input with the candidate list. On non-SDL windows like foot, GTK, etc. the candidate list shows up fine, even in fullscreen. On SDL however it works in windowed mode but if I put it in fullscreen the candidate list doesn't appear. I can still type text and press enter, and pretext works, just not the candidate list popup. Please let me know if it is reproducible or not in case it is not an SDL issue.

Used SuperTuxKart and osu!lazer

[flibitijibibo]

Here's where SDL implements the protocol for input rectangle: https://github.com/libsdl-org/SDL/blob/main/src/video/wayland/SDL_waylandkeyboard.c#L55

This has been checked under other compositors and with ibus, not sure about fcitx. Quick search suggested native Wayland might have been an issue at one point:

https://github.com/fcitx/fcitx5/issues/206#issuecomment-762511291

(The author actually submitted some patches for both X and Wayland support recently, so I'd expect this to work!)

[diagonalisability]

I can't reproduce this issue, Fcitx5's candidate list doesn't flicker for me on a fullscreen SDL window. Maybe this was fixed, or maybe this was a Sway bug?

• Sway version 1.7
• SDL version 2.24 (also tried most recent commit, 6af1736)

I tried building that Sway PR, but it doesn't build with the latest version of Wlroots.

[diagonalisability]

I was able to build that Sway PR by rebasing it onto Sway master, but I still can't reproduce this bug.

• Sway commit I rebased onto: 9400bd9
• Latest Wlroots commit: 0c962c9
• Programs I've tested: Osu Lazer, this minimal SDL program

[layercak3]

I'm in sway 9400bd963c59fd59f597c1477b8021a82ca0a72e, wlroots eeb7a8113869790e5f6fc643bafa577b08b5f4c3, fcitx5 da7c3ceda592558728108603c1d936f4230c8f96, sdl2 2.24.1

I've used https://github.com/swaywm/sway/pull/5890, https://github.com/swaywm/sway/pull/7226, and https://aur.archlinux.org/cgit/aur.git/tree/0001-text_input-Implement-input-method-popups.patch?h=sway-im-git implementations and got the same issue in supertuxkart and osu lazer (IME popup not visible unless not in fullscreen, can sometimes see it flicker very slightly in osu when typing. Happens in mozc, and table methods like IPA-X-SAMPA). I could try reproducing in a vm, testing default config and screen record the issue in the coming days if I have some time

[diagonalisability]

I'm also not getting any flickering in Supertuxkart, the candidate list displays fine. I've tried using Fcitx5 with Mozc, and I've tried both Sway 1.7 and Sway master + https://github.com/swaywm/sway/pull/5890. Does this bug happen for you when you use Sway 1.7 without any additional commits?

[layercak3]

Sorry for the long delay. I am using SDL 9e8d2f3948139d71fd29cd69e42733e9c5a24582 and rebased https://github.com/swaywm/sway/pull/7226 on sway https://github.com/swaywm/sway/commit/5543acff06981639086bc9a0fc9b608796a23e84 (commit of 1.7 release), and got the same behaviour as before. Note I have always used the HEAD of wlroots master, not a release ver

[layercak3]

I found a clue. When I set my output (display) to a scale that is fractional, I can see it (tested 0.5, 1.1, 0.9, 2.9, even stuff like 0.999999 works where it looks almost identical to 1). But when I am using an integer scale (tested 1, 2, 3) I don't see it. (also I switched back to sway HEAD)

[Kontrabant]

If it only happens when fractional scaling is used, this sounds like it might be related to the window using a viewport, which happens when fractional scaling (or fake fullscreen modes) are used. It might be a compositor issue in that case.

[flibitijibibo]

@AtticFinder65536, if we have a test program to identify this would it be possible to file this with the sway team? It could genuinely be our bug but it'd be a good to get a confirmation from the compositor side that we're doing something wrong in the fractional scale scenario.

[icculus]

I'm bumping from the milestone, since we're out of time, and it looks like it needs more research still.

[flibitijibibo]

Was looking at the sway patch, and I wonder if this has anything to do with it (open up text_input.c and it'll highlight it)...

https://github.com/swaywm/sway/pull/7226/files#diff-58653e4a25a6380a65e2c8a3e3c39ec5a56d3c1f93d5ac53591e47bd2ad6203cR145

Could be that this works for the viewported path but not the unviewported? This is a wild guess though, I'm just skimming around for any path that might vary based on scale mode.

[layercak3]

@AtticFinder65536, if we have a test program to identify this would it be possible to file this with the sway team? It could genuinely be our bug but it'd be a good to get a confirmation from the compositor side that we're doing something wrong in the fractional scale scenario.

It would be a bug in the PR and not sway itself as it hasn't been merged yet, so I'm sure it wouldn't be a valid report on the issue tracker but it would probably be ok to ask on IRC or something

https://github.com/swaywm/sway/pull/7226/files#diff-58653e4a25a6380a65e2c8a3e3c39ec5a56d3c1f93d5ac53591e47bd2ad6203cR145

I set popup->visible in line 152 to a true condition, but that didn't change anything. There are some reviews in tadeokondrak/input-method-popups although I believe they have been mostly addressed by Decodetalkers/input-method-popups or not relevant. I don't know enough about C or Wayland to know if the PR's implementation is correct

[flibitijibibo]

Posted in that sway PR and it ended up getting closed, ha... @AtticFinder65536: They're now recommending a different patchset, maybe that will fix it? If not, definitely let them know; they're now aware of SDL's issue but any updates would be good for them to have.

[Decodetalkers]

Posted in that sway PR and it ended up getting closed, ha... @AtticFinder65536: They're now recommending a different patchset, maybe that will fix it? If not, definitely let them know; they're now aware of SDL's issue but any updates would be good for them to have.

Emm.. I still cannot repreduces it ..

I can only reproduce it after scale is changed

I don't think it has anything to do with his pull request, his pull request is handle input-method_v2, and the popup is not created by his code..

[flibitijibibo]

I think the scale change is what we're looking at - any idea if that's something on our end? I don't recall if we do scaling work in our text input system but I'm also not sure how scale interacts with text-input-v3.

For reference...

• Text input implementation https://github.com/libsdl-org/SDL/blob/main/src/video/wayland/SDL_waylandkeyboard.c
• Text input callbacks https://github.com/libsdl-org/SDL/blob/main/src/video/wayland/SDL_waylandevents.c#L1942

[flibitijibibo]

I was going through all the Wayland issues and noticed something with this one... hopefully it's not related, but: Is everyone testing with SDL_VIDEODRIVER=wayland? It's possible this only affects Xwayland (but it would still be an issue, just for the x11 driver instead).

[layercak3]

Sorry for the inactivity. I am using SDL_VIDEODRIVER=wayland, the containers are using xdg_shell. About the previous theory, I think it wasn't showing because of direct scan-out. When another surface like mako or wob is displaying over the fullscreen window in layer-shell, the IME is visible (direct scan-out is not happening anymore). I suspect using fractional scaling prevents direct scan-out from occuring, but that is a guess. I don't know if direct scan-out is something that only occurs in some clients like SDL has done which revealed this issue in the sway PR, or if SDL is doing something that causes it to erroneously go into direct scan-out even when an IME is being displayed which would make it invisible.

[q234rty]

After testing with env SDL_VIDEODRIVER=wayland supertuxkart on Arch Linux, I found that this does happen https://github.com/swaywm/sway/commit/b757ef94ef15093b8851598f85ef047379c341b5 + https://github.com/swaywm/sway/pull/7226 but no longer happens with https://github.com/swaywm/sway/commit/b28e1b0d3c4ab90dc7e0516078e1e3f332981f37 + https://github.com/swaywm/sway/pull/7226. So it seems like @AtticFinder65536 's findings are correct and this issue can be considered fixed?

[flibitijibibo]

I'd have to agree as well, so I think we're good to go! If it turns out we're wrong this can be reopened.