An X11 Apologist Tries Wayland (artemis.sh)
It feels fantastic. It even made my software cursor not feel so softwarey, which I’ve never experienced with a software cursor before. I have a pretty bad GPU, but on a higher end card you’d get a huge benefit to this in games. If your card can render the game many times faster than your monitor refresh rate, you can unlock your FPS in the game, tune your max_render_time to the absolute minimum, and get EXTREMELY low latency while still having absolutely no screen tearing whatsoever.And like, this is the first time I’ve ever seen the vsync setting in a game actually sync the game up with the vblank interval in a way that matters. It works for games in wine. It’s amazing. I have never experienced gaming on Linux that looked this smooth in my life.
Posted Sep 19, 2022 7:13 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (3 responses)
I posted about my experience here. The updates to that are: 1. screen-mirroring to external display (eg projector) works great with "wl-mirror", better than actual mirroring since it works with your laptop resolution regardless of resolution of the external display. 2. reportedly zoom client screensharing works now, but I haven't tried it, I use firefox for zoom and screensharing (full screen only) is flawless.
And, lastly, it's great that wlroots seems to be becoming a standard for non-GNOME non-KDE desktops. It appears that xfce and others are eyeing it too. Of note, Simon Ser "emersion" is the maintainer of sway and a maintainer of both wlroots and wayland itself. So it all looks in good hands.
Posted Sep 19, 2022 7:47 UTC (Mon)
by WolfWings (subscriber, #56790)
[Link] (2 responses)
Hopefully the nouveau driver can integrate all the good bits from the knowledge the open-sourced NVidia chunks allow for over the near year, so 2023 or 2024 I'll be able to make the leap, especially having played with Wayland stuff more on the Steam Deck now.
Posted Sep 19, 2022 7:53 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Sep 19, 2022 16:45 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
Posted Sep 19, 2022 9:03 UTC (Mon)
by taladar (subscriber, #68407)
[Link] (28 responses)
I have a xmonad config (e.g. force certain layouts for certain programs, put each program on the named workspace where it belongs,...) and various small shell scripts (e.g. screen locking on inactivity but don't if videos are playing, screenshots with automatic naming by date, screenshots of QR-Codes for OATH 2FA, various copy&paste related stuff,...) that I would all have to replace to move to Wayland.
Meanwhile wayland libraries on Rust, my current preferred program language appear to be pretty much dead (e.g. wlroots bindings last updated in 2019) and every time I look into Wayland I find various things that are supposed to not work yet (e.g. screen sharing in at least one if not multiple of the video conferencing systems I need for work).
I am highly sceptical of these 'works for me' type of posts written shortly after someone switches or while someone temporarily tries Wayland (meaning they haven't encountered their own rarer use-cases yet). I believe that it works for 80% of use-cases but why would I invest lots of work to go from a system that works fine for 100% of my use-cases to one that only works for 80% and for benefits like the ones mentioned in this article I really, really don't care about like low latency gaming (all my gaming works fine on X11 and if anything it seems some games that work on X11 won't work at all on Wayland judging by steam forums)?
Not to mention that I consider the whole compositor concept highly flawed for anyone who, like me, doesn't care about flashy windowing effects like transparency. Why burden everyone who just wants to manage their windows with implementing that separately?
Posted Sep 19, 2022 9:31 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (2 responses)
There's also smithay for rust users, which apparently is being used by system76 for an upcoming wayland DE+compositor.
But if you're an xmonad power user, wayland is not for you, unless you want to work on a replacement (there was waymonad but it seems to be dead).
Posted Sep 20, 2022 7:46 UTC (Tue)
by taladar (subscriber, #68407)
[Link] (1 responses)
What I don't like is going to some low-level language like C or downgrading to mere config from being able to use an actual programming language to configure my WM.
I am also not particular fond of the notion that whatever I choose will also be responsible for compositing graphics in some way instead of just making policy decisions on window management.
And of course, as mentioned, doing all of that up front before I even really know if Wayland is going to be any good for me.
Posted Sep 20, 2022 11:02 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
As a fellow XMonad user, this is the same situation I'm in.
> I am also not particular fond of the notion that whatever I choose will also be responsible for compositing graphics in some way instead of just making policy decisions on window management.
The separate process thing doesn't really work with Wayland due to the security model. I mean, someone could make a channel that slings metadata and rectangle coordinates around to make external decisions…but why? I suspect that the closest thing we'll get to XMonad is a Rust compositor that embeds WASM to load the configuration (so that it can be hotloaded without restarting the process).
Posted Sep 19, 2022 9:43 UTC (Mon)
by gspr (subscriber, #91542)
[Link]
Back when I had trouble getting this to work reliably (it works fine for me now, I think WirePlumber/Pipewire is playing a role behind the scenes?), a workaround I used was to temporarily run the screensharing stuff under XWayland. IIRC, this made the sharing software completely oblivious to anything except other X windows, but that was good enough as a workaround.
Posted Sep 19, 2022 10:16 UTC (Mon)
by q3cpma (subscriber, #120859)
[Link] (19 responses)
Some other websites I found very useful about this:
Posted Sep 19, 2022 10:42 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (5 responses)
Posted Sep 20, 2022 0:19 UTC (Tue)
by q3cpma (subscriber, #120859)
[Link] (3 responses)
Posted Sep 20, 2022 0:36 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
Posted Sep 20, 2022 3:13 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Sep 20, 2022 7:08 UTC (Tue)
by abo (subscriber, #77288)
[Link]
Posted Sep 20, 2022 3:12 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Sep 19, 2022 11:23 UTC (Mon)
by nix (subscriber, #2304)
[Link] (6 responses)
Most of them have hotkey-driven tabbing and splitting (a la terminator), large-scale layout restoration (just what you need if like me you have a dozen terminals you want instantiated on different virtual desktops every time you start up); all the VTE ones at least have infinite-length scrollback (via a compressed, encrypted, unlinked file in /tmp, so it's pretty safe from info leakage as these things go), and the GPU-acceleration means screen refresh even on high-res displays is instantaneous and it scrolls in an unreadable flashing blur, which is surely what everyone really needs from a terminal emulator? (What do you mean you can't read a screen that's only displayed for 7ms?). And most of them have (unlike in days of yore) actually paid attention to the specs and (more importantly) what xterm does, and tried to implement a terminal that doesn't get things gratuitously wrong.
Posted Sep 19, 2022 11:34 UTC (Mon)
by q3cpma (subscriber, #120859)
[Link] (5 responses)
>Most of them have hotkey-driven tabbing...
Posted Sep 19, 2022 17:33 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
How would you implement true scrollback in tmux without terminal-level support?
Posted Sep 20, 2022 0:12 UTC (Tue)
by q3cpma (subscriber, #120859)
[Link]
But some features like keyboard input multiplexed to a group of windows (terminator) is unheard of in any WM to me. Maybe could be done in some very hacker-friendly ones like stumpwm or using http://hea-www.harvard.edu/~fine/Tech/xlax.html (I love those obscure and/or magic X11 including xdo, xdotool, wmctrl, wmutils, etc...).
Posted Sep 19, 2022 17:53 UTC (Mon)
by nyanpasu64 (guest, #135579)
[Link] (2 responses)
Posted Sep 19, 2022 21:07 UTC (Mon)
by erincandescent (subscriber, #141058)
[Link] (1 responses)
Posted Sep 20, 2022 7:42 UTC (Tue)
by taladar (subscriber, #68407)
[Link]
Posted Sep 19, 2022 15:08 UTC (Mon)
by stephen.pollei (subscriber, #125364)
[Link] (3 responses)
Posted Sep 19, 2022 21:24 UTC (Mon)
by dskoll (subscriber, #1630)
[Link]
The last time I looked (which admittedly was a very long time ago) Tk's Windows back-end implemented compatibility code that made it "look like" Xlib calls to the rest of Tk. I guess this solution could work with Wayland too, and probably wouldn't require a ton of code.
Posted Sep 20, 2022 1:22 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Sep 20, 2022 8:10 UTC (Tue)
by gspr (subscriber, #91542)
[Link]
XWayland doesn't have the same scaling capabilities as Wayland. If you use such scaling, your XWayland windows may look terrible compared to your native Wayland ones.
Posted Sep 19, 2022 16:54 UTC (Mon)
by anarcat (subscriber, #66354)
[Link] (1 responses)
Posted Sep 20, 2022 0:01 UTC (Tue)
by q3cpma (subscriber, #120859)
[Link]
I'd say that imlib2 looks quite good, now that the developement picked up steam
Posted Sep 19, 2022 15:18 UTC (Mon)
by flussence (guest, #85566)
[Link] (3 responses)
It's been a complete non-starter for me for more basic reasons. I start X as a runit service and hand off the cookie file to the user-level session in a separate process tree. The server runs as root out of necessity, but there's no suid invocations, no privilege elevation, and no rube goldberg chicken-sacrificing rituals.
To do something equivalent in Wayland land I'd need to A) label all keyboard/pointer devices in udev so the unprivileged user can snoop them directly (!), and B) either run the desktop god-process as root (no) or with raised capabilities to grab a VT without root (from what scant documentation I can find, exactly which caps are needed varies _by DRI driver_ and nobody will utter a straight answer).
The fundamentals don't work after 40 years, and the official line is that you have to paper over the cracks with load-bearing wallpaper (pam, javascript and logind). You can't accelerate out of a car crash, and I'm not getting in that passenger seat.
Posted Sep 19, 2022 17:46 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Uhm... You do realize that X applications can do that using the very X11 protocol without any extra permissions?
You are also incorrect in that you can snoop HID devices from an unrelated process. Wayland should use EVIOCGRAB ioctl to exclusively bind devices to one session (via `open_restricted` in libinput).
If you want to be even more secure, you can segregate device opening into a separate context and just pass FDs from this context. A small on-demand service activated via systemd would work nicely.
Posted Sep 20, 2022 0:35 UTC (Tue)
by raof (subscriber, #57409)
[Link]
Why? Xorg has been able to run without root for many years.
> either run the desktop god-process as root (no) or with raised capabilities to grab a VT without root (from what scant documentation I can find, exactly which caps are needed varies _by DRI driver_ and nobody will utter a straight answer).
Why do you need a VT? The first process to open the DRM device automatically gains DRM master (which is all you need for display); your only problem should be allowing the compositor access to input devices. logind (or, it seems, seatd if you're looking for a lighter alternative) is what would handle that in a regular setup, but if you've already got a separate process tree for your user session you *could* just make them world-readable but run the user-session tree in a new cgroup and remove all input devices from that tree's device cgroup.
You have a weird setup. That's fine! But “it doesn't work exactly the way my existing weird setup does” isn't a very useful complaint. There are ways to get approximately the same result as you do now (indeed, with substantially better security properties, like “user processes can't trivially snoop all input”), they just require you to figure them out as you originally did with your existing setup.
Posted Sep 20, 2022 0:44 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
None of this is true. I start sway from a tty by typing "sway". No sudo, no suid bits, no special udev rules. Works on my laptop with intel graphics and work desktop with nvidia (yes it works these days). You can also start sway from gdm.
Posted Sep 19, 2022 9:25 UTC (Mon)
by atai (subscriber, #10977)
[Link] (2 responses)
Posted Sep 19, 2022 9:48 UTC (Mon)
by gspr (subscriber, #91542)
[Link]
[1] https://gitlab.freedesktop.org/mstoeckl/waypipe/
[2] https://manpages.debian.org/unstable/waypipe/waypipe.1.en...
Posted Sep 19, 2022 16:12 UTC (Mon)
by njs (guest, #40338)
[Link]
Posted Sep 19, 2022 14:52 UTC (Mon)
by NightMonkey (subscriber, #23051)
[Link] (22 responses)
I'm going to miss network-traversing X apps. It still feels magical to me to be able to run an X application on one host and have its window show up on another. And it can be practical, as well (like when I need to run Pulseaudio preference apps from a headless Raspberry Pi on my laptop).
Last I asked, this will never be possible in Wayland. :(
Posted Sep 19, 2022 15:46 UTC (Mon)
by pothos (subscriber, #116075)
[Link] (9 responses)
Posted Sep 19, 2022 21:05 UTC (Mon)
by lamikr (guest, #2289)
[Link] (8 responses)
Posted Sep 20, 2022 7:58 UTC (Tue)
by gspr (subscriber, #91542)
[Link] (7 responses)
One solution is to use Waypipe. Then both computers need Waypipe installed. It's available in several distros at this point. If your distro doesn't offer it, you can build it from source. Then it's as simple as running A small caveat is that Waypipe currently does not do any endianness matching, so both computers need to have the same endianness. The developer is aware and is considering how best to solve this.
Posted Sep 21, 2022 14:42 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (6 responses)
But does it mean that it won't support remote X11 apps ? I mean, the beauty of X11 is its universality. It's available on every operating system (even Windows) and is used to display xterms, editors, and even full sessions running on remote systems from various editors (done it a lot from Linux, Solaris, Tru64, AIX and possibly even others I don't have in mind right now). *That* is what made it last this long. So at least you'll need an X server that can display in wayland to be able to support all such applications.
I know that some developers recently tend to ignore the distributed aspect of X11 and that's sad, because I recently discovered for example that firefox was not able to finish loading via a WiFi network, using a steady 30 Mbps of X11 traffic while idle. There's definitely something that was done wrong there, considering that years ago I was routinely using Firefox 4.76 over SSH over ADSL :-(
Posted Sep 21, 2022 14:53 UTC (Wed)
by daenzer (subscriber, #7050)
[Link] (3 responses)
No, both Waypipe and X11 forwarding work in the same SSH connection. It's possible to choose which to use per application.
Posted Sep 21, 2022 23:01 UTC (Wed)
by lamikr (guest, #2289)
[Link] (2 responses)
waypipe ssh username@host2 weston-terminal
and both of them opened well and I was also able to do the browsing well. Both of the pc's were on same network so I can not yet comment from the possible behaviour in case of slower network.
Two addon questions came to my mind:
1) Does anybody know commands how to launch either the gnome desktop or gdm (to login to gnome) by using the waypipe?
2) Would it be possible to access the 3rd PC via 2:en PC with some kind of waypipe tunneling?
Posted Sep 22, 2022 8:42 UTC (Thu)
by daenzer (subscriber, #7050)
[Link]
I doubt that's possible for GDM, since GDM is all about local VTs.
There are ways of running a nested gnome-shell, but AFAIK none of them directly use Wayland on the backend.
> 2) Would it be possible to access the 3rd PC via 2:en PC with some kind of waypipe tunneling?
It just works, same as for X11 forwarding:
1. waypipe ssh "second pc 2 behind nat"
Wayland applications launched from the resulting shell run on the 3rd PC and display on the laptop PC 1. (Note that this is obviously less efficient than connecting directly to the target machine, when possible)
Posted Sep 22, 2022 9:40 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link]
If you use ssh's ProxyJump (ssh -J jumphost finalhost), it looks no different from a direct ssh to the final host to anything traveling through the SSH connection.
Posted Sep 22, 2022 6:50 UTC (Thu)
by jem (subscriber, #24231)
[Link] (1 responses)
X11 has lost its universality in the sense that not all X11 applications can be used remotely, at least not easily. In fact, as I understand it, the advent of direct rendering was the motivation for Wayland. The X server didn't do much useful work anymore, so it was time to cut out the middle man.
Posted Sep 22, 2022 8:25 UTC (Thu)
by geert (subscriber, #98403)
[Link]
Posted Sep 19, 2022 16:28 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (11 responses)
It's ALWAYS been possible in Wayland. As always, I suspect the new-technology-haters have been spreading their lack of knowledge.
The answer I always got was "it's possible but no one can be bothered to scratch that itch". I'm glad it appears someone finally has.
(Wayland is a *protocol* - alll you need do is pipe it across the network!)
Cheers,
Posted Sep 19, 2022 17:22 UTC (Mon)
by syrjala (subscriber, #47399)
[Link] (10 responses)
Posted Sep 19, 2022 17:41 UTC (Mon)
by atnot (subscriber, #124910)
[Link] (6 responses)
Posted Sep 20, 2022 10:03 UTC (Tue)
by syrjala (subscriber, #47399)
[Link] (5 responses)
Posted Sep 20, 2022 13:38 UTC (Tue)
by mrugiero (guest, #153040)
[Link] (4 responses)
If the applications don't use the drawing commands, then you send no drawing commands.
Posted Sep 20, 2022 14:11 UTC (Tue)
by syrjala (subscriber, #47399)
[Link] (3 responses)
Anyways this is all easy enough for you to try yourself. Just use ssh forwarding and if your client works then it has a non-shm codepath, since Xorg disables shm for non-local clients.
Posted Sep 20, 2022 14:32 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
Cheers,
Posted Sep 20, 2022 18:26 UTC (Tue)
by jem (subscriber, #24231)
[Link] (1 responses)
The Wayland designers did not try to reinvent every wheel, they took parts of the X11 system that were applicable to the new system, like XKB. We also have to recall that KDE is based on Qt, and there is only one set of Qt libraries that serve both X11 and Wayland. You can select whether you want an X11 session or Wayland session in the display manager menu, and the appearance is more or less the same. Even if you choose a Wayland session, there's of course the XWayland X11 server process, which is started by kwin_wayland, and exists for backwards compatibility with legacy X11 programs. Then there's the display manager sddm, which is the "recommended display manager for KDE Plasma", and for some reason it still runs on top of a "real" X11 server. So yes, if you look at process listings and shared library dependencies you see a lot of X11 names flying by, even when choosing to run a Wayland session of KDE Plasma. But the important point is that none of the Wayland-aware apps (e.g. all the KDE apps that come with KDE Plasma, Firefox, Emacs, etc.) talk to an X server when started in a Wayland session.
Posted Sep 22, 2022 6:34 UTC (Thu)
by AdamW (subscriber, #48457)
[Link]
It can run on top of Wayland, and for the last few fedora releases we've tried doing it that way, but there turn out to be problems that make us keep kicking it back to X. The most prominent is that, er, logging out doesn't work. The second most prominent is that keyboard layout selection doesn't work.
Posted Sep 19, 2022 17:41 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
The compositor is told what to display. How on earth does your LOCAL compositor know what to display, if the protocol doesn't tell it?
And if the protocol can tell it to display an image, it surely can tell it *what* image to display, and then surely (if it's not done by default!) it's precious little effort to inline that image.
(I understand one of the design aims of Wayland, was to be ABLE to do everything X can, other than those things that are forbidden by the Wayland security model (you know, those things that X can do to compromise a system because it always had to run as root ...)
Cheers,
Posted Sep 19, 2022 21:38 UTC (Mon)
by dullfire (guest, #111432)
[Link]
I suggest reading the core wayland protocol. It's very short.
However, in brief, wayland handles negotiating fd's for mmap-ing or other side-band IPC for display payload transfer. It's very much does NOT do in-band image transfer. This can sort-of be worked around with a proxy... but that proxy has to understand every supported buffer mechanism (I know of 2 buffer types off the top of my head, but only shared temp fds, think memfd, is in specified in-protocol. The other I know of uses DRI buffers... forgot it's name).
Posted Sep 20, 2022 1:36 UTC (Tue)
by jem (subscriber, #24231)
[Link]
The client does the drawing. The compositor/window manager tells the client "Here's a surface and an associated buffer. Go wild, I don't care what you draw." The compositor handles the windows and input devices (e.g. mouse), and informs the correct client of a mouse click using window local coordinates.
Posted Sep 19, 2022 17:42 UTC (Mon)
by nyanpasu64 (guest, #135579)
[Link] (3 responses)
For example, bsnes, higan, bsnes-plus, etc. only allow adjusting PulseAudio audio latency in intervals of 20ms, and the minimum of 20ms feels acceptable but not instant on pipewire-pulse. RetroArch on PulseAudio/PipeWire, using the ALSA or PulseAudio backends, cannot achieve stable latency below 2-3 video frames, and its JACK backend is disabled on Flatpak and Arch Linux packages (and manually rebuilding with it enabled reveals it's no better than ALSA/Pulse at achieving single-digit ms latency). This is shocking considering it goes to extreme lengths to reduce video latency (frame delay much like Sway's max_render_time but now with automated tuning, runahead literally time-traveling the emulator to skip past games' built-in input delay, even a dedicated CRT SwitchRes mode for the obscure practice of running HDMI ports at super-resolutions like 2560x240 and feeding through a HDMI to component converter to plug into a CRT, to shave precious milliseconds of latency and achieve a more authentic image). And playing Stray on Bottles has a noticeable delay of sound behind video, even *with* Bottles's option to *reduce* (?!) PulseAudio latency to 40 ms checked.
As for solutions, PipeWire comes with deterministic low audio latency (because it's a pull-mode synchronized API to PulseAudio's push-mode buffered API), much the same way the author is trying to tune Wayland's compositing timing behavior. And it supports audio mixing (unlike ALSA) and supports ALSA/PulseAudio apps (unlike jackd), though PipeWire cannot add deterministic low latency behavior to PulseAudio apps, or ALSA apps (I do believe this is solvable with some buffering trickery, but I don't understand PipeWire's client API and proper implementations like pipewire-jack or SDL well enough to do so).
Posted Sep 19, 2022 21:17 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
The problem is that most audio is playback. Latency is irrelevant, what matters is stutter.
Yes, professional audio, latency is vital, but how often do you need a computer audio stream to merge with an analogue data stream? That is, sadly, a minority use case.
So long as the buffer doesn't run out, 99% of applications couldn't give a monkeys about latency. :-(
Cheers,
Posted Sep 19, 2022 22:07 UTC (Mon)
by nyanpasu64 (guest, #135579)
[Link]
Posted Sep 25, 2022 14:36 UTC (Sun)
by flussence (guest, #85566)
[Link]
Measurably defective software, and the unique gimmicks don't make up for that.
Posted Sep 19, 2022 22:27 UTC (Mon)
by WhatsInAName (guest, #128037)
[Link] (22 responses)
Posted Sep 20, 2022 3:30 UTC (Tue)
by Baughn (subscriber, #124425)
[Link] (4 responses)
Afraid you'll have to wait some more.
Posted Sep 20, 2022 9:27 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (3 responses)
Posted Sep 20, 2022 16:41 UTC (Tue)
by Baughn (subscriber, #124425)
[Link] (2 responses)
But whatever the cause, the net effect is I'm still on X11, and will be for the time being.
Posted Sep 21, 2022 7:17 UTC (Wed)
by WolfWings (subscriber, #56790)
[Link]
It's rather shocking how much software just breaks utterly at 40Hz or 120Hz on Linux right now, TBH.
Posted Sep 21, 2022 7:28 UTC (Wed)
by daenzer (subscriber, #7050)
[Link]
Posted Sep 20, 2022 13:46 UTC (Tue)
by mrugiero (guest, #153040)
[Link]
Posted Sep 20, 2022 15:07 UTC (Tue)
by dvdeug (subscriber, #10998)
[Link] (15 responses)
Posted Sep 20, 2022 15:34 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
It also doesn't demand that it's better than the stuff that came before, just that it gets sufficient PHB buy in ... (which is why you get hold-outs :-)
Cheers,
Posted Sep 21, 2022 15:02 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (13 responses)
It's not just this, it's that there are lot of people for whom it took a long time to figure a more or less nicely working setup by combining the required parts and the required glue, and who are pissed off when someone decides to reinvent something without first considering improving what already exists, and without enumerating the list of features to make sure they will not be dropped. I'm not saying it's the case here with wayland, I don't know it, I've never tried it and until today I thought it was a window manager. It's just a general observation that working stuff that doesn't evolve much thanks to no more needs tends to be the target of people in search of a project to bring quick fame, that usually only solves their lack of knowledge of the first product by reimplementing what they didn't know already existed and dropping other parts they didn't know existed. Sometimes there are improvements for certain use cases, but at the expense of just dropping support for a lot of well-established ones. And again it's possibly not the case here so I'm not judging on that one.
So it's not a matter of users being "wedded", but users finally adopting Linux only once it matches their needs, and that not breaking their use case by pure ignorance is important to keep these users. Actually for 20 years we've heard that "next year is the year of linux on the desktop", yet MacOS has gained way more users in the same timeframe. I'm not a mac user at all, but I suspect they're more careful about not constantly replacing everything for their users, or at least trying to emulate what used to work before.
We're speaking about users here, not mere consumers. When you use your OS for everyday job, you know that at some point an upgrade will give you an extremely bad day/week/month/year. Nobody wants to experience this when your PC is the link between you and your work.
Posted Sep 21, 2022 15:34 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (11 responses)
Considering that, in this particular case, one of the major movers behind Wayland was for many years (until Xorg kicked him out) the *sole* developer of X11, it's unlikely.
As I've said elsewhere, the aim behind the design of Wayland was "to make possible everything currently in X11, unless it breaks a sane security model" (which, seeing as X didn't have said sane model, means a lot of stuff did, sadly, break ...).
But like I said elsewhere, when I asked about remote forwarding, the answer I always got was "it's possible, nobody's bothered to scratch that itch". Now it's been scratched :-)
Cheers,
Posted Sep 22, 2022 9:06 UTC (Thu)
by daenzer (subscriber, #7050)
[Link] (10 responses)
I'm not sure who you're referring to; I can't remember any developer ever getting "kicked out by X.org", and there hasn't ever been a sole developer of X11.
It is true though that Kristian Høgsberg Kristensen worked on improving X for many years, before he finally realized that some of its issues just were unfixable by design, and created Wayland. Similarly, many other former (and current, such as yours truly) X developers are now involved in Wayland development. One could say Wayland is the spiritual successor to X.
Posted Sep 22, 2022 11:13 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (9 responses)
But yes, aiui one of the big driving forces behind Wayland (X13 :-) was the realisation that many of its worst flaws were basic design faults.
Cheers,
Posted Sep 22, 2022 12:11 UTC (Thu)
by jem (subscriber, #24231)
[Link] (8 responses)
I wouldn't put it that way. X11 was designed in a world where a Sun-2 workstation with its bitmap display was state of the art, and (physical) text terminals connected to a central computer were still on the way out. "The network" still referred to the local LAN. X11 worked great in this environment, but that was 30+ years ago.
Posted Sep 22, 2022 16:58 UTC (Thu)
by anton (subscriber, #25547)
[Link] (1 responses)
Posted Sep 23, 2022 10:04 UTC (Fri)
by paulj (subscriber, #341)
[Link]
Posted Sep 22, 2022 23:03 UTC (Thu)
by ianmcc (subscriber, #88379)
[Link] (5 responses)
I also remember a few occasions where random windows suddenly appeared on my screen, from someone who had set their DISPLAY variable incorrectly. Fun times!
Posted Sep 23, 2022 8:30 UTC (Fri)
by geert (subscriber, #98403)
[Link] (4 responses)
Fortunately we got ssh, and ssh -X, and life was good ;-)
Posted Sep 23, 2022 13:26 UTC (Fri)
by corbet (editor, #1)
[Link] (3 responses)
Posted Oct 8, 2022 8:22 UTC (Sat)
by sammythesnake (guest, #17693)
[Link] (2 responses)
Oh dear, I may be the evil twin :-/
Posted Oct 8, 2022 11:25 UTC (Sat)
by amacater (subscriber, #790)
[Link]
Posted Oct 8, 2022 13:17 UTC (Sat)
by micka (subscriber, #38720)
[Link]
Posted Sep 21, 2022 18:51 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
This…is exactly the opposite of what Apple does IME. Deprecation windows are very short and changes can come with little to no warning (because nothing can be announced before it's on the Big Stage for their annual "we'll deign to allow you to prostrate yourselves at our feet in person" conference). Of course, users tend to be of a "oh, the new stuff is completely better; why would anyone have ever done it any other way" mindset.
Posted Sep 20, 2022 6:08 UTC (Tue)
by SomeOtherGuy (guest, #151918)
[Link] (13 responses)
That's a huge dealbreaking problem.
I do it mostly over LAN too and with -C it's usable over wifi for things that draw bitmaps.
Whenever I've looked at this I can see no universal workaround. I admit some stuff doesn't work over -X (like certain openGL things) but by and far everything I could possibly want or use (except firefox) does.
Posted Sep 20, 2022 8:06 UTC (Tue)
by gspr (subscriber, #91542)
[Link] (12 responses)
Waypipe is one possible replacement. Then you replace
Posted Sep 20, 2022 8:16 UTC (Tue)
by gspr (subscriber, #91542)
[Link] (11 responses)
I ended on a downside (lack of universal availibility), so I'll add some upsides: You point out that
Posted Sep 20, 2022 9:13 UTC (Tue)
by SomeOtherGuy (guest, #151918)
[Link] (10 responses)
For a great many applications they're sort of there locally, for example typing in a text input DEFINITELY doesn't incur a round-trip-delay, nor does clicking a button (even if the result of doing it does).
I also like that I usually get my native themes (somehow) too.
Interacting with a video is far from the same thing.
One thing I really like for example is eom (eye-of-mate - the MATE image viewer) - if you load a big image it can take a while as it sends it, but once there you can pan and zoom.
I don't see how Wayland could match that - even if waypipe means I'm not totally screwed, it's not the same thing.
Posted Sep 20, 2022 9:28 UTC (Tue)
by gspr (subscriber, #91542)
[Link] (3 responses)
Then Waypipe comes, says "what I'm really transferring is *moving images*, I better treat it accordingly" and shoves a compressed video stream over the network.
> I also like that I usually get my native themes (somehow) too.
Fair enough.
> One thing I really like for example is eom (eye-of-mate - the MATE image viewer) - if you load a big image it can take a while as it sends it, but once there you can pan and zoom.
Hmm. I've never been able to reliably scroll even simple websites in Firefox over ssh -X, but it's a breeze with Waypipe.
> I don't see how Wayland could match that - even if waypipe means I'm not totally screwed, it's not the same thing.
It's not the same thing. I'd say it's better, though. It's usable and responsive even for complex apps over weak connections. Yes, you do lose local theming, but you get a lot in return.
Posted Sep 20, 2022 16:36 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (2 responses)
Firefox works much better via Waypipe than via X11 over SSH for me as well. I've seen the opposite case with other apps though. Luckily, it's possible to choose one or the other case-by-case in a Wayland session.
Another advantage of Waypipe vs X11 over SSH is that hardware accelerated direct rendering can work.
Posted Sep 23, 2022 7:04 UTC (Fri)
by SomeOtherGuy (guest, #151918)
[Link] (1 responses)
Firefox doesn't work AT ALL over ssh -X, because it uses OpenGL or weird DRM (not rights management, the other one) rendering, only ancient open GL calls are proxied across.
So firefox over ssh -X shouldn't work at all....
You might get the profile selector, but that's it.
Posted Sep 23, 2022 7:48 UTC (Fri)
by daenzer (subscriber, #7050)
[Link]
Works here, comes up with WebRender in software mode. It performs much worse than via Waypipe though, even with WebRender hardware acceleration disabled for the latter as well (WebRender works with hardware acceleration via Waypipe though).
> because it uses OpenGL or weird DRM (not rights management, the other one) rendering, only ancient open GL calls are proxied across.
I suspect you mean that WebRender now uses EGL, whereas only GLX indirect rendering can provide at least some hardware acceleration with X11 over SSH. EGL can work fine with software rendering though.
I suspect you're hitting a bug somewhere.
Posted Sep 20, 2022 9:33 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (5 responses)
It really is pretty much exactly the same thing as X11 forwarding over SSH (which BTW doesn't use X's network transparency features). Both use a proxy display server on the SSH server side.
Arguably the biggest difference at this point is that waypipe isn't integrated into OpenSSH (yet?).
Posted Sep 20, 2022 9:48 UTC (Tue)
by gspr (subscriber, #91542)
[Link] (4 responses)
I'm a big fan of Waypipe (and the maintainer of its Debian package), but it seems way too drastic to drag video compression infrastructure into something like OpenSSH.
Posted Sep 20, 2022 10:00 UTC (Tue)
by dullfire (guest, #111432)
[Link] (3 responses)
I haven't looked into the technical details of waypipe, but if it really is capable of stuffing wayland + display images down a tcp socket, then a simple ssh shell script wrapper (because the ssh client invocation would be convoluted), on the client side and on the host maybe some shell rc config and MAYBE a few lines in the ssh_config should be enough to get waypipe working "transparently" in a similar way to ssh+x11 forwarding.
(all of that said: I don't use waypipe, so its highly likely I have over simplified some things... or maybe am even wrong, lol)
Posted Sep 20, 2022 10:24 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (2 responses)
That couldn't work, since X servers haven't listened to any network ports by default since xserver 1.17, released in February 2015.
Posted Sep 20, 2022 10:42 UTC (Tue)
by dullfire (guest, #111432)
[Link] (1 responses)
> ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections, arbitrary TCP ports and UNIX-domain sockets can also be forwarded over the secure channel.
It would be better to say that its port/socket forwarding. My point being: There isn't any "X11" code in ssh beyond env setup, and port &| socket forwarding.
Further more, if waypipe is able to use a tcp socket, then it should be easy to wrap in an ssh session, without any ssh server/client code changes.
Posted Sep 20, 2022 13:32 UTC (Tue)
by Gaelan (subscriber, #145108)
[Link]
I believe that's exactly what waypipe does.
Posted Sep 22, 2022 9:06 UTC (Thu)
by kucharsk (subscriber, #115077)
[Link]
$ xset dpms force off
to manually shut off a monitor using DPMS as of yet?
The answers I've found online indicate solutions that might work IF you have a particular option package installed AND you have a particular GPU, but nothing as easy as the "xset dpms" command.
Posted Oct 1, 2022 11:31 UTC (Sat)
by JanC_ (guest, #34940)
[Link]
As long as they don’t fix that, I don’t consider Wayland to be ready for daily use…
Posted Oct 1, 2022 11:52 UTC (Sat)
by geert (subscriber, #98403)
[Link] (8 responses)
Conclusion: not yet ready for production, set WaylandEnable=false in /etc/gdm3/custom.conf and move on...
[1] I believe this needs waypipe on both machines, -ENOTYETPACKAGED, at least on the other machine.
Posted Oct 1, 2022 14:19 UTC (Sat)
by daenzer (subscriber, #7050)
[Link] (7 responses)
ssh -X works fine with Xwayland[0]. I could only speculate on the reason why it didn’t work for you without more information, but „Wayland is not ready“ is definitely not it.
[0] To an X server, ssh -X is just a local client like any other. Discriminating against it would require active effort. So assuming any X client works, there’s no reason why ssh -X couldn’t.
> (I believe this needs waypipe on both machines, -ENOTYETPACKAGED?),
Waypipe is only needed for native Wayland clients, it has nothing to do with ssh -X (other than it works by the same principle). The same SSH connection can support both, and it’s possible to choose one or the other per application.
> - After opening 3 terminal windows, two of them keep on shrinking every time the focus is changed[2],
That’s a bug either in the terminal application, one of the libraries it uses, or in the Wayland compositor. Note that the bug reports referenced on the askubuntu page are all about an X session, no Wayland involved.
> Conclusion: not yet ready for production, set WaylandEnable=false in /etc/gdm3/custom.conf and move on...
WaylandEnable=false makes it impossible to log into any Wayland session. There‘s no need for that; just choose an X session when logging in. GDM remembers the chosen session and pre-selects it next time.
Posted Jan 4, 2023 12:55 UTC (Wed)
by geert (subscriber, #98403)
[Link] (6 responses)
> > - "ssh -X" to another machine no longer works[1]
It seems the issue is that inside mate-terminal, both $DISPLAY and $WAYLAND_DISPLAY are "wayland-0", hence "ssh -X" doesn't work. Worse, launching local X apps from mate-terminal no longer works neither.
> > - After opening 3 terminal windows, two of them keep on shrinking every time the focus is changed[2],
So this must be another issue in mate-terminal that is not yet fixed (I switched from gnome-terminal to mate-terminal a few years ago, when they dropped the ability to configure the character set for word selection).
> > Conclusion: not yet ready for production, set WaylandEnable=false in /etc/gdm3/custom.conf and move on...
Time to file some bug reports...
Posted Jan 11, 2023 13:45 UTC (Wed)
by geert (subscriber, #98403)
[Link] (4 responses)
Posted Jan 11, 2023 17:42 UTC (Wed)
by jem (subscriber, #24231)
[Link] (3 responses)
Wayland clients can't position themselves on the screen. See The Wayland Book for the reasoning. Xeyes is an X11 app that is running under XWayland, therefore it can position itself. Xeyes is also a good example of a program for demonstrating how X11 programs can spy on you: it follows every move you make with your mouse. Wayland prevents this – Xeyes does not know where the mouse pointer is when it is hovering over a Wayland window.
Posted Jan 13, 2023 10:07 UTC (Fri)
by geert (subscriber, #98403)
[Link] (2 responses)
How unfortunate. So this is the responsibility of the compositor (mutter?). Is there a way to configure this in mutter?
> Xeyes is an X11 app that is running under XWayland, therefore it can position itself.
Interesting. AFAIU, Xwayland is a layer on top of Wayland. So how can X11 apps still position themselves?
Posted Jan 13, 2023 15:14 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
Just an educated guess here -- Xwayland knows the dimensions of the screen it's running on, allocates a surface covering the entire screen, and it can then place windows wherever it wants within that (mostly transparent) surface, based on the X11 protocol's support for applications to request specific window positions (and generally be aware of *everything* every other X11 application is doing)
Posted Jan 15, 2023 18:30 UTC (Sun)
by jem (subscriber, #24231)
[Link]
See: https://wayland.freedesktop.org/docs/html/ch05.html
I guess the X11 window manager allows the apps to position their windows themselves for backward compatibility, since that has been an essential feature of X11 from the beginning.
As always, it is worth repeating that the term "Wayland compositor" is generic, and there are several independent implementations.
Posted May 12, 2023 9:30 UTC (Fri)
by geert (subscriber, #98403)
[Link]
Having done the i3→sway move about a year ago, I fully agree. I too was reluctant to abandon x11 but it seemed clear that the move will be needed one day, and to my surprise there were really no showstoppers and a lot of things worked better than on i3/x11.
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
About wlroots-rs, it looks like Simon Ser (sway lead, wlroots and wayland maintainer) has just revived it. However, it's early days.
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
* bspwm: https://github.com/riverwm/river + https://github.com/jonbkei/riverbsp ?
* sxhkd: https://github.com/waycrate/swhkd until there's a dedicated protocol (https://gitlab.freedesktop.org/wayland/wayland-protocols/...)
* dmenu: nothing as light, as expected from Wayland, but https://github.com/Cloudef/bemenu or https://codeberg.org/dnkl/fuzzel is probably the best choice
* lemonbar: no replacement that is as hacker-friendly, https://codeberg.org/dnkl/yambar is the only one that doesn't depend on GTK; probably my biggest gripe
* st: https://github.com/michaelforney/st and https://github.com/majestrate/wterm are dead (so is wld), the only sane and "light" choice is https://codeberg.org/dnkl/foot/; otherwise it's all "GPU-accelerated" Rust contraptions with Node-tier dependency trees, VTE stuff or Kitty made by a someone who refuses patches to allow bitmap fonts
* sxiv: imv is better designed, but FreeImage is a dumpster fire that's also a security disaster just waiting to happen and imv lacks too much format support without it (e.g. Webp, netpbm, TGA, etc...); I may write more backends if I get the time, one day (heh)
* mupdf: Zathura as a mupdf frontend works, but I'd prefer pure mupdf, personally
* emacs: forced to use the GTK frontend instead of the perfect and lightweight athena/Xaw one
* Nyxt: I think it's okay, since it uses webkit-gtk-2
* Tk, McCLIM and countless other tookits away from the GTK/Qt hegemony: dead
https://arewewaylandyet.com/
https://hacktivis.me/notes/pure-wayland.shtml
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
otherwise it's all "GPU-accelerated" Rust contraptions with Node-tier dependency trees, VTE stuff or Kitty made by a someone who refuses patches to allow bitmap fonts
Presumably the latter part is code for "only uses Fontconfig, and recent Fontconfig has dropped bitmap font support"? It turns out... it hasn't! What has actually happened is that support for Type 1 and X bitmap fonts is gone (which is very annoying if like me you have a huge library of them), but OpenType can represent bitmap fonts fine and everything can still render those, and FontForge can convert the former into the latter. There just aren't many of them yet. I should try making an OTF wrapping jmk-neep one of these days, because many of these newer terminals are seriously amazing to use.
An X11 Apologist Tries Wayland (artemis.sh)
No, it rejects font with the scalable property.
cf https://github.com/kovidgoyal/kitty/issues/97#issuecommen...
I'm a suckless kind of guy, I like simple code and clean separation of roles (e.g. don't include tmux in your terminal emulator). I did use the word "contraption", after all; "usine à gaz" in french also fits.
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
SSH already has a feature enabling connection reuse. Add something like
An X11 Apologist Tries Wayland (artemis.sh)
Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%n:%p
ControlPersist 1m
to your ~/.ssh/config
An X11 Apologist Tries Wayland (artemis.sh)
Tk backend for Wayland
Tk backend for Wayland
Tk backend for Wayland
Tk backend for Wayland
An X11 Apologist Tries Wayland (artemis.sh)
* sxiv: imv is better designed, but FreeImage is a dumpster fire that's also a security disaster just waiting to happen and imv lacks too much format support without it (e.g. Webp, netpbm, TGA, etc...); I may write more backends if I get the time, one day (heh)
Could you expand on this? It feels like *all* image renderers (hello libpng and image magick!) are kind of dumpster fires, security wise... but is FreeImage specifically bad in that regard?
Asking for a friend looking for wayland alternatives... ;)
An X11 Apologist Tries Wayland (artemis.sh)
Massive library bundling + very slow/dead developement (last release 2018).
again. For example, if we compare 1.7.1 (latest in Gentoo) with 1.9.1, we got
XBM, AVIF, HEIF, JPEG XL, SVG, JPEG2000, PS/EPS support and WEBP, ICO, GIF,
(A)PNG, JPEG XL multiframe support.
Just need nsxiv to be adapted, for X11 users.
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
To do something equivalent in Wayland land I'd need to A) label all keyboard/pointer devices in udev so the unprivileged user can snoop them directly (!), and B) either run the desktop god-process as root (no) or with raised capabilities to grab a VT without root (from what scant documentation I can find, exactly which caps are needed varies _by DRI driver_ and nobody will utter a straight answer).
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
waypipe ssh user@computer1 gnome-calc on computer 2.An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Just to be clear, that you need to build pipewire on both computers to be able to use it. I tested both the firefox and westor-terminal by using commands:
waypipe ssh username@host2 firefox
(laptop pc 1 --> second pc 2 behind nat --> 3rd pc accessible via second pc that's on same network with pc2)
I think this could work with ssh -X, but not sure how to do with waypipe?
An X11 Apologist Tries Wayland (artemis.sh)
> (laptop pc 1 --> second pc 2 behind nat --> 3rd pc accessible via second pc that's on same network with pc2)
> I think this could work with ssh -X, but not sure how to do with waypipe?
2. In the resulting shell, waypipe ssh "3rd pc accessible via second pc"
An X11 Apologist Tries Wayland (artemis.sh)
(laptop pc 1 --> second pc 2 behind nat --> 3rd pc accessible via second pc that's on same network with pc2)
I think this could work with ssh -X, but not sure how to do with waypipe?
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Wol
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
What exactly is "most things"? AFAICT, "most things" is either "uses Qt" or "uses GTK". Can you confirm these still support sending those commands?
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Wol
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Wol
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Wol
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Wol
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Wol
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
Wol
An X11 Apologist Tries Wayland (artemis.sh)
And yet X11 works nicely with X servers on my Skylake desktop or (until Ubuntu 22.04, where wakeup after suspend does not work with X11, and barely with Wayland) on my Tiger Lake laptop, and with clients on many machines, not just in LAN, but also across international Internet connections. Admittedly, there are a few client applications that no longer work well remotely (e.g., firefox), but most of the stuff I use is workable remotely.
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
And everything ran over unencrypted channels (telnet/rlogin/rsh/ftp/...), even when talking to a machine on the other side of the globe.
The xhost + days were good, though...I miss the thrill of running xroach on some random scientist's display and hearing the screaming from down the hall...:)
xhost +
xhost +
xhost +
xhost +
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
ssh -X host command with waypipe ssh host command. Granted, Waypipe isn't universally available on every host. But it works well.An X11 Apologist Tries Wayland (artemis.sh)
ssh -X really needs a LAN connection to be comfortable, and often doesn't work well with complicated stuff like Firefox. The good news is that Waypipe works quite well even over a not-so-great Internet connection, even running Firefox! Instead of degrading the draw rate to the point of becoming unusable, it exhibits video compression artifacts. I'd much rather take some blur and ghosting than a framerate of 0.1 when scrolling down a web page in Firefox.An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
An X11 Apologist Tries Wayland (artemis.sh)
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
Issues I ran into:
- "ssh -X" to another machine no longer works[1] (I believe this needs waypipe on both machines, -ENOTYETPACKAGED?),
- After opening 3 terminal windows, two of them keep on shrinking every time the focus is changed[2],
- When resizing a terminal window, it no longer shows the size (IIRC, I had to install some extension to get this working before, too).
[2] https://askubuntu.com/questions/1408101/how-do-i-stop-my-...
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
> ssh -X works fine with Xwayland[0]. I could only speculate on the reason why it didn’t work for you without more information, but „Wayland is not ready“ is definitely not it.
> [0] To an X server, ssh -X is just a local client like any other. Discriminating against it would require active effort. So assuming any X client works, there’s no reason why ssh -X couldn’t.
Inside gnome-terminal, $DISPLAY is ":0", so local X and X forwarding both work.
> That’s a bug either in the terminal application, one of the libraries it uses, or in the Wayland compositor. Note that the bug reports referenced on the askubuntu page are all about an X session, no Wayland involved.
> WaylandEnable=false makes it impossible to log into any Wayland session. There‘s no need for that; just choose an X session when logging in. GDM remembers the chosen session and pre-selects it next time.
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
Interestingly, it still works for e.g. xeyes.
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
> Interesting. AFAIU, Xwayland is a layer on top of Wayland. So how can X11 apps still position themselves?
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
X->Wayland->X (Upgrading to Ubuntu 22.04LTS)
After 3 weeks, I don't regret switching back.