Hacker News Reader

Comment by creata | Hacker News Reader

If it's not too much trouble, can you list the software you use which doesn't work on Wayland?

No problem, the biggest ones I tried were Godot, Krita, and Steam. Godot does not run on Wayland although support seems to be planned somewhere down the pipeline. Krita "runs" on Wayland but a lot of the features do not work nor does pen support last time I checked. Steam just doesn't work.

Edit: A commenter on this thread mentioned Emacs. I have not tried that as I have recently switched to Emacs but if that is true then that would also be a big one for me.

On my ASUS PN50 APU, Steam works fine in wayland, even in big picture mode. Input, however, is another (sad) story.

I have a Linux PC that my kids mostly use, running Wayland sessions. It definitely works with Steam and Krita, although I admit that I do not know if all of Krita's features work. They have played Portal 2, Minecraft, and a few "windows-only" games with Proton.

My biggest gripe is that if you have more than one window of Chrome open it gets VERY slow. Multiple tabs are good, multiple windows are not.

>Multiple tabs are good, multiple windows are not.

"It's a perfect compositor, as long as it is not expected to composite." ;)

Personally I need the ability to open a remote window on my desktop, fingers crossed that someone will add that.

I'm pretty sure that it's a bug in Chrome / Chromium since other applications are just fine even when Chrome is being dog slow.

If every other compositor/desktop system/whatever it is, is running fine, but not with Wayland, then how is it a Chrome 'bug'?

Chrome has separate code for dealing with each compositor. The bug would be in the code that deals with Wayland specifically.

If every other application / process is running fine, but not Chrome, then how is it a Wayland 'bug'?

https://bugs.chromium.org/p/chromium/issues/detail?id=112178...

Chrome regressed on Wayland after changing the default rendering path on Linux. The slowness seems to be a problem in getting proper vsync, and there are multiple cases where it was/is causing issues.

Chrome doesn’t even run on wayland, unless compiled specifically on a new enough branch so OP talks about the version running inside XWayland. It can possibly be a bug in the specific compositor’s xwayland implementation or even in chrome. Also, your special ability to try out every compositors must be really useful.

This should help you:

chromium --enable-features=UseOzonePlatform --ozone-platform=wayland & disown & exit

You can also adjust your .desktop Chrome launcher to use these flags

This is good info. I'll spin up a VM running Sway or something and give it another go and see what roadblocks I hit.

Basically all GTK2 apps won't work.

They won't be native but of course they just work via xwayland

swaywm (Wayland) runs Krita and Steam just fine. Don't use Godot, so can't tell anything about it.

Emacs and Steam seem to work for me - I've been using it with XWayland for around a year now.

Godot and Steam work perfectly fine on Wayland.

> Steam just doesn't work.

Steam works fine. What exactly doesn't work for you?

It's a couple of years old, but this post on "Why I'm not going to switch to Wayland yet."[1] summarizes some of the concerns I have about switching to Wayland:

"at the moment there are several types of applications that not only don't work in wayland, but would be very difficult, or impossible to work natively in all major wayland compositors.

Examples (in order of importance to me):

  * Programmatic output configuration (xrandr, arandr, etc.)
  * CLI clipboard access (xsel, xclip)
  * Third party app launcher/window switcher (rofi, dmenu, albert, docky).
  * Clipboard managers (parcellite, klipper, Gpaste, clipman, etc.)
  * Third party screen shot/capture/share (shutter, OBS, ffmpeg, import, peek, scrot, VNC, etc.)
  * Color picker (gpick, gcolor3, kcolorchooser)
  * xdotool

Until Wayland has all these (and more) and they are as stable and feature-rich as the existing apps on X, I will not willingly switch to Wayland.

PS: ydotool has been touted as an equivalent of xdotool, but ydotool has only a tiny fraction of the features of xdotool.

And it's unlikely that it'll get much better any time soon, as its README says:

"Since Jun, 2019, I have little time to maintain this project"

wtype is supposed to be another equivalent to xdotool, but it has even less features than ydotool.

If the rest of Wayland's X equivalents as feature poor as these, I don't hold out much hope for Wayland in the near future.

[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...

  * It's not exactly the same, but I use Kanshi for dynamic output configuration. https://github.com/emersion/kanshi
  * https://github.com/bugaevc/wl-clipboard
  * https://hg.sr.ht/~scoopta/wofi
  * https://github.com/yory8/clipman
  * There's wlrobs for OBS. There's grim/slurp/wl-recorder for use outside of OBS.
  * You can use grim to grab a particular color on the screen, but the UI wouldn't be as good, of course.

xeyes

https://blogs.gnome.org/wjjt/2012/03/14/looking-around-wayla...

Emacs

Please see https://news.ycombinator.com/item?id=26002420

Emacs works perfectly fine under xwayland. The recent pgtk feature branch does not use X anymore under wayland. What is not working for you?

Yes, when Wayland acts like X then X apps sometimes work. In the process you abandon the security and performance features of Wayland.

Getting xwayland working is another story. I can't seem to get it to work at all on my PinePhone; but to Wayland's credit, the phone crashes for all sorts of reasons.

Yeah, Wayland needs to act like X when using a pure X application.

But emacs X/"gtk" frontend has been controversial for a few reasons, with work having been under way for quite a while for a new frontend, somewhat unrelated to Wayland.

Xwayland not working on pinephone is ironically primarily an X problem, as Xwayland is just xorg-server compiled with only the Wayland backend enabled.

And, as there are little to no xorg developers, fixing xorg is proving tricky as there is no one to make a new xorg release...

Why would you abandon the security of wayland by an xwayland app? It only sees at most other xwayland apps.

As for the pinephone part, I may not understand your point about “to Wayland’s credit”, do you think stability issues on the pinephone is due to wayland?

The PinePhone has unstable hardware, it doesn't matter if I run X or Wayland and it doesn't matter what distribution I use. I can't keep it operating for more than 5 minutes before the screen goes to blank and/or it gets stuck in an endless reboot cycle that requires removing the battery to halt.

Which distro? I have one as well and at least under mobian , while it is really far from stable, it works. But reboot cycles sound like a hardware bug rather than unstable hardware.

I've tried:

    Ubuntu Touch
    Mobian (phosh)
    PostmarketOS (sxmo, phosh)
    Manjaro (Phosh, Plasma and Lomiri)

And multiple release versions of each; using multiple different sdcards as well as the on-board memory.

The only OS that doesn't exhibit the reboot/black-screen issues for me is the one used to allow flashing of the device over USB.

The factory test software works, all of the different OS variants; so if there is a hardware issue the factory test software isn't able to detect it. Notably, I've left the test software running without issue.

I've even tried turning off all the hardware dip switches.

Interesting, but if you really are enthusiastic about the pinephone than perhaps try to order another motherboard (I’m thinking about it because the older has only 2 GB of ram)

I've got the Manjaro CE version, so it should be new enough. I'm also not flush wish cash, so... Yah, I'll be buying diapers for my toddler, not a motherboard that may or may not work.

It's a shame, 'cause I really like the concept, and bought it for myself as a birthday gift. Thought it would be a fun project to hack on.

Yeah, I hear you and I am sad that your unit probably has some issue.. perhaps writing an email asking for a replacement?

I'll give that a shot, but AFAICT from the forum discussions, Pine isn't to amenable to shipping replacements without paying for them.

The note "segfaults on multiple displays" in the readme made me stay away from that.

I have been plugging and unplugging multiple displays into my laptop since March. Usually I have emacs running locally (xwayland) and an emacsclient over X11 to a remote server. I have not experienced any issues so far. Maybe the readme is too conservative in this regard?

Someone is working on that: https://github.com/masm11/emacs

Reply on news.ycombinator.com