3 ms·
Ah yes, sway, the one of the waylands that refuses to add support for complex mouse/keyboard and alternate input devices. https://github.com/swaywm/wlroots/issu
by superkuh 3y ago
Ah yes, sway, the one of the waylands that refuses to add support for complex mouse/keyboard and alternate input devices. https://github.com/swaywm/wlroots/issues/2378 https://github.com/swaywm/wlroots/issues/2378 . You've been running a wayland, not wayland, because there is no "wayland": only many different waylands.
- craftkiller 3y ago> You've been running a wayland, not wayland, because there is no "wayland": only many different waylands. I am aware, that is why I specified which compositor I am running. The comment I replied to said (emphasis mine) "*Wayland* won't work well on non-Linux systems" which is clearly false. To put it into another context: only a subset of C programs run on windows, but it would be silly to claim C won't work on windows. As for the bug report you linked, the response seems quite reasonable: > We already have Wayland protocols for input emulation. I think libei should add support for those. Since standardized protocols exist, why should every compositor have to integrate this library instead of the library integrating support for the standardized protocols?
- superkuh 3y ago>support for the standardized protocols? What standardized protocol? Each wayland makes a different choice. That's the problem. And yeah, I guess I can't say this is a sway issue, their choice is reasonable enough. But it highlights how reasonable actions in a broken system like the waylands can cause problems. They're not doing anything "wrong" and neither are the waylands using libei (all the mouse/keyboard sharing programs target libei, maybe in the future some can target whatever sway comes up with). But it does lead to things not working across waylands. Whereas in X things do work no matter what X implementation you use.