Hacker News Reader

Comment by o11c | Hacker News Reader

For me, the quickest way to tell that I'm running on Wayland is seeing if multi-lingual keyboard input is broken. I have right-alt-while-pressed set to switch to a Greek layout (because who doesn't math?), and it reliably works on X11 but breaks in all sorts of weird ways under Wayland (sometimes it simply fails to enable/disable, sometimes it shows a notification as if it changed but switches back when input actually happens, ...).

On the bright side I'm finally learning how Vim's digraphs work.

View on HN

Both Xorg and Wayland compositors use libinput, so it's probably more to do with lack of decent configuration support in your DE or WM. You can always configure libinput manually. Sway just lets you add libinput configs inline inside your sway config.

[edit]

This is probably not relevant (assuming correct wayland libinput config), since this is not where mult-lingual input transformations live. libinput just handles the physical keyboard mapping and behaviour.

On more careful reading of the parent this sounds more like a buggy input method editor.. or maybe an issue with switching between X and wayland apps.

Is (simple, so e.g. non-CJK) multilingual input a libinput thing? I thought it was a libxkbcommon thing.

NO! my mistake, I latched onto keyboard input and didn't think about multi-lingual. I'm guessing you mean things like pinyin, I think that's a dbus thing, which is still a thing on wayland but I don't really know anything about this... I'll get my coat.

That still boils down to a Wayland design issue, since Wayland requires each individual DE/WM to get support for such features while X only needs them in Xorg.

But why are management and handling of language-dependent input methods supposed to be in Xorg?

What happened to separation of concerns?

"Do one thing and do it well"?

More like do a thing and do it once. If every WM and DE needs to do it, you have some that don't, or you have issues that are handled correctly by some DEs and not others, etc.

We're still talking about Linux, are we?

Snark aside, it's still orthogonal to my question. I wasn't questioning whether it should be done centralized, but why it's supposed to be part of the display server protocol/compositor.

Because the "display" server is also responsible for window management and input. Does it have to be this way? Perhaps not - but seperating window management and input is also not trivial.

Note that more complex input methods do somewhat bypass the display server and communicate via dbus instead.

> "Do one thing and do it well"?

Did you miss the do it well part? Nearly every unix tool does more than one thing, the alternative would be a usability nightmare.

* grep, which primarily does pattern matching has dozens of file traversal related flags that could be handled by calling it from find

* find, a tool supposed to find files for some reason has dozens of flags related to executing applications which could probably be done by using xargs

* did you know that xargs can do pattern matching and replacement on its input string? there are probably dozens of unix tools that are specialized for that

X11 eventually punted the whole thing to each individual application. For input methods like Fcitx or IBus to work reliably on modern X11 programs, you need to set envvars like the following [0]:

    GTK_IM_MODULE=fcitx
    QT_IM_MODULE=fcitx
    SDL_IM_MODULE=fcitx

[0]: https://wiki.archlinux.org/title/Fcitx5#IM_modules

That seems weird complaint about Wayland, Wayland requires every server to support these features, just like X11 also requires every server to support them? Sure, there weren't that many X11 server implementations so maybe it was not so apparent, but as a protocol they seem pretty much equal in this regard.

The criticism is that Wayland duplicates a lot of effort in multiple compositors. The compositor does work that happens in Xorg and in the WM. Whereas lots of common functionality gets implemented in Xorg that WMs and DEs don't need to duplicate.

It's not a weird complaint when on X11 when something is added it generally works for everyone whereas for Wayland the different implementators are still squabbling how to accomplish basic functionality people expect from their desktop computer.

Or in other words, your comparison is like saying food and shit are basically the same thing because both are made up of similar elements.

But wayland merges more components into one server than X11 did. Therefore, there is a need for more wayland server then there was a need for X11 servers.

Xorg can use libinput but is not limited to that.

Neither are Wayland compositors.

Hear, hear.

KDE just elected improving the Input story in its bi-annual community wide goals election: https://kde.org/goals/

Multilingual keyboard input is such a mess haha. I need to type a lot of Chinese using pinyin and still haven't found a reasonably polished implementation on Wayland (Sway) that works on both Xwayland and true Wayland applications. So I reverted to i3 with ibus.

For what it's worth, the latest 1.10 release of sway introduced support for IME popups. Maybe that would help

Another way to check if you're running on Wayland is to start some 3D accelerated application and see if the screen is all flickery. Apparently Wayland has some issue with not generating a frame sync that causes all variety of problems, but usually lots of flicker.

Really? My laptop has my national keyboard but I switch to USA for programming because of {} [] and all the other characters that can be typed with minimal use of extra keys. My fingers know the keys and the switch combination, maybe windows + space. I didn't expect Wayland not to have such basic functionality after so many years. But frames must be perfect, no tearing (is that the word?)

It's possible that the "permanently switch to next layout" works reliably, but not the "switch while held" (which I do because I'm selecting single symbols at a time)?

Have you tried using a compose key? I lost my custom mappings when switching from X to Wayland, but they work fine in both.

I did lose my custom mappings though, but I only needed them when I was in emacs and obviously there's already a command for inserting weird stuff, so I just added a binding for it.

I use the compose key for compose stuff. It's a huge pain to actually write and install custom compositions so I don't bother anymore, just use the defaults (which is mostly annoying due to missing keypad variants, e.g. ± must be typed using the top of the keyboard).

It looks like the default en_US.UTF-8/Compose includes mappings of the form:

  <dead_greek> <a>  : "α"

but to use that I'd have to figure out how to map a key to `<dead_greek>`, and keyboard mappings that aren't in the standard checkboxes are such a pain.

> It's a huge pain to actually write and install custom compositions

Could you say more about this?

IME, it's just a matter of adding lines to ~/.XCompose — is there something I'm missing?

Is ~/.XComposed picked up anymore? At least it wasn't early on, and I just gave up on keeping it around.

I guess it's up to each Wayland compositor, which calls for inconsistency :/

My understanding is that generally, Wayland uses XKB, which respects ~/.XCompose

But I think there are specific exceptions still, such as this Chromium bug: https://issues.chromium.org/issues/40272818

Any chance you typo'd the file name then, like you did here?

Tried it again and it works!

I'm guessing that maybe I forgot to restart the machine to make sure everything got to read it. Or that whatever was broken long ago got fixed.

BTW, I can't reach my backup right now, but this seems like a good start to build up custom mappings in case anyone gets interested in this, https://github.com/kragen/xcompose

If you use Xorg sure. If you use wayland it can't be done.

I think you're mistaken. You can use .XCompose on Wayland (modulo certain broken cases, perhaps).

The Wayland book recommends XKB: https://wayland-book.com/seat/xkb.html

It does come down to the libraries used by a given app, though (see sibling comment).

Even with Xorg toolkit support has degraded quite a bit. For GTK it doesn't work by default and you need to set GTK_IM_MODULE=xim in your environment. Qt on the other hand picks up ~/.XCompose by default but truncates the compose result to one character.

compose key on wayland is why I don't use wayland :D

Reply on news.ycombinator.com