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.
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.
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.
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.
* 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.
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.
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.
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?
