rvaiya / keyd

A key remapping daemon for linux.
MIT License
2.71k stars 157 forks source link

Unicode input doesn't work on chrome+wayland. #273

Open rvaiya opened 2 years ago

rvaiya commented 2 years ago

It appears that chrome's wayland ozone implementation (platform abstraction layer) completely ignores the XCompose file, breaking unicode input. This affects all chromium based browsers (e.g brave) running with the experimental --ozone-platform=wayland flags and is likely the root cause of #196 and https://github.com/rvaiya/keyd/issues/31#issuecomment-1205735475.

The current solution is simply to run chrome using XWayland (the default behaviour in the absence of such flags), since this is a bug in chrome and native wayland support is currently marked as experimental anyway.

Additional Notes:

Appending --gtk-version=4 will cause chrome to use gtk4 (if it is installed) for input processing, which does account for ~/.XCompose, however gtk4 compose handling is also broken (it doesn't handle large compose files properly) and will cause the process to crash (a veritable improvement). The gtk bug is potentially fixable by judiciously pruning the shipped XCompose file.

Refs:

https://source.chromium.org/chromium/chromium/src/+/main:ui/base/ime/character_composer.cc https://bugs.chromium.org/p/chromium/issues/detail?id=1183262 https://source.chromium.org/chromium/chromium/src/+/main:ui/base/ime/character_composer_sequences.txt (builtin compose table generated from X keysyms) https://source.chromium.org/chromium/chromium/src/+/main:third_party/wayland-protocols/gtk/gtk/gtkimcontextsimple.c

rvaiya commented 2 years ago

Related: #285

joihn commented 1 year ago

Since GTK4 are becomming more common, a warning in the man page could be usefull in the unicode section edit: https://github.com/rvaiya/keyd/pull/540