Comment by stevepike | Hacker News Reader

Comment by stevepike | Hacker News Reader

Parent Full thread

Ok, here is my use case that wayland doesn't work for. I have an AMD graphics card (5700xt) and two 4k screens. I want to run firefox, chrome, emacs, and a terminal.

Using KDE or Sway, if I set my desktop scaling to 2x, all programs that run through XWayland have extremely blurry display (they've been rendered at 1x and then crudely scaled up). This includes firefox, chrome, and emacs. The browsers have ongoing work to support wayland natively, but neither is stable for me.

If I set my desktop scaling to 1x, I can then scale up individual xwayland programs with flags like `--force-device-scale-factor` if they support them. This gets me close to the behavior on X but on X I can just set a global 2x scale.

I totally understand the frustration of OSS maintainers when people demand they fix things with no intention of getting into the code. On the other hand, the marketing behind wayland encourages some unrealistic expectations. I went out and bought a new graphics card and it turns out I can't even run firefox! That was not what I expected to happen.

A pgtk build of emacs is what I have been using for quite some time without any significant problems (native Wayland build)

https://github.com/masm11/emacs

Pretty sure there are builds for the browsers you mentioned that run natively on wayland

Yeah, here's where I think things tend to go off the rails in the wayland discussions with people having different personal experiences. I've tried to run both firefox and chrome in the native wayland mode and neither works properly _for me_. I forget what the chrome issue was, but in firefox on KWIN if I enlarge a window the portion of the window that was added doesn't render properly --- it's a flashing white rectangle --- and then if I resize it down it either crashes or garbles the whole window. I'm sure this doesn't happen to everyone.

Not sure about emacs but Chrome and Firefox can run under Wayland native these days though still a bit off from them using it on a default launch I think. As for the general workaround you landed on that kind of approach is probably still the best approach at the moment. You can also set the scaling algorithm to something else (I prefer nearest neighbor) if that helps any. There was a PR to support setting X hidpi for XWayland but it got held up somewhere in XWayland stuff apparently.

Definitely a painful use case combination still but one that should solve itself once things actually start using Wayland rather than XWayland.

Is the scaling algorithm specific to the wayland implementation? I saw a github thread about configuring it in sway but wasn't able to find anything about KWIN. I'd also love a flag to just disable scaling on a per-xwayland-app basis (so I could use the --force-device-scale-factor hack) but couldn't figure out how to do that so if you know something off the top of your head it'd really help out.

Anyway thanks for the tip!

Reply on news.ycombinator.com