This has been reported to Alacritty in https://github.com/jwilm/alacritty/issues/2750.
It seems like certain locales (for example eo) cause xkbcommon to fail on Wayland. As a result of that, it is not possible to input any characters.
This does not seem to be an issue on X11.
This is the full xkbcommon error output:
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:83:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:84:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:85:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:86:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:87:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:88:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:89:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:90:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:91:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:92:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:93:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:93:29: too many errors
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:93:29: failed to parse file
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:83:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:84:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:85:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:86:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:87:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:88:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:89:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:90:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:91:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:92:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:93:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:93:29: too many errors
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-3/Compose:93:29: failed to parse file
Doing some quick digging, it looks like libxkbcommon doesn't really like non-utf8 locales...
Not sure if we can do something about that. Maybe SCTK doesn't handle gracefully enough a failure to load the compose state. I'll check.
Not sure if we can do something about that
It seems like this locale is only available in non-utf8 though. So it would be extremely unfortunate to just out-right block certain locales.
Ok, so there was indeed a bug in SCTK causing it to completely fail any utf8 interpretation of the inputs if loading the compose table failed. https://github.com/Smithay/client-toolkit/commit/22aabc383b83aabe4bbee1cceba30682927024d8 should fix it, I'll make a new patch-release soon.
SCTK 0.6.4 is released with this fix.
So, this will not make all the warnings stop, but at least it should no longer prevent winit from getting utf8 interpretation of the input keys.
Is there any way to make libxkbcommon load non-utf8 locales? That seems like a quite severe limitation.
Apparently it's voluntarily not supported, though it specifically affects the compose API only: https://github.com/xkbcommon/libxkbcommon/issues/76
No one is using a non-UTF-8 local these days
Right.
But I guess there's nothing left to do then.
@vberger The sctk version is released and the latest version of winit has this resolved.
Do you think that resolves this issue and the remaining problems are just an upstream limitation we have to live with? Or is there any plan to fix this?
I think we can close this, I don't see libxkbcommon changing wrt to that anytime soon.