- cross-posted to:
- linux@programming.dev
- technews@radiation.party
- cross-posted to:
- linux@programming.dev
- technews@radiation.party
In response to Wayland Breaks Your Bad Software
I say that the technical merits are irrelevant because I don’t believe that they’re a major factor any more in most people moving or not moving to Wayland.
With only a slight amount of generalization, none of these people will be moved by Wayland’s technical merits. The energetic people who could be persuaded by technical merits to go through switching desktop environments or in some cases replacing hardware (or accepting limited features) have mostly moved to Wayland already. The people who remain on X are there either because they don’t want to rebuild their desktop environment, they don’t want to do without features and performance they currently have, or their Linux distribution doesn’t think their desktop should switch to Wayland yet.
That’s a big one. All the *BSD folk will keep on using X at least until it gets proper support over there (which might never happen) and even then it will still be boycotted by some BSD users for other reasons.
I agree about that. Many people don’t care and will just use whatever their distro tells them to use. As you said, there’s usually good reason for it.
This is another one, and is actually one I kinda fall under. I use a tiling window manager. The tiling Wayland compositors are often times not as polished, and a big annoyance for me personally is the fact that most of them (River, Hyprland, DWL) don’t come with a bar. Of my X Window Managers, AwesomeWM, DWM and Qtile already have their own bars. BSPWM is basically supposed to be used with Polybar, the same way XMonad and xmobar are basically made for each other. On Wayland, Somebar is made for DWL, but waybar and yambar work really well with it. Sway has swaybar, but waybar works perfectly with it. Both Waybar and yambar work great with River. And there’s Waybar, and gBar, and other bars for Hyprland. And that’s without mentioning EWW, which can be used to make a bar.
Another issue I have is that my touchpad doesn’t get detected if I’m holding down a key. So if I’m playing Minecraft and I’m trying to turn around and run away from a zombie using my touchpad because my mouse’s battery ran out, I have to do these actions one by one and hope I survive, or just let myself die. That’s just an example, but I have noticed it in other games as well. No such issues on X. And I’ve also had Powerwash Simulator, ran through wine, just crash on me in some (Qtile or Hyprland), but not other compositors. In DWL, I couldn’t turn all the way around and forbsome reason my movement was restricted to 270°, and in River I had 0 issues.
You’re saying this as if X didn’t have a monopoly over Unix graphics.
That’s a libinput feature, meant to prevent you from accidentally using the touchpad when you’re typing. You can disable it if you want.
How? Would that be in the compositor input rules or somewhere else?
I don’t know how to configure libinput under ${YOUR_FAVORITE_COMPOSITOR}, you’ll have to figure that out yourself. In Plasma it’s simply in the touchpad settings
Okay, my point was it is in input settings, not some strange configuration.
If I run Satisfactory via Vulkan on X, it causes my entire desktop to flicker until I close the game, on all screens. Annoying, but at least I can make it go away.
If I run Satisfactory via Vulkan on Wayland, it crashes Wayland and my entire computer freezes until I hard reboot it by pressing the power button. That is absolutely unacceptable.
(Satisfactory on DX12 works fine for both, but the point is Wayland is still much more likely to fail catastrophically.)
NVIDIA?
AMD, Mesa.
Interesting, what WINE compat layer are you using for Satisfactory then? Proton, Wine, Wine-GE?
Steam has it on Proton 8-6, running Satisfactory Experimental.