Live data from Hacker News

An X11 apologist tries Wayland

artemis.sh

301–310 of 453 posts

Re: An X11 apologist tries Wayland

#301

Earlier quoted context omitted.

You can also use Gimp via a RDP or VNC session, which will give much better performance on low-bandwidth connections, since those protocols do damage detection, only sending updates of what's changed, and (lossy) compression. I'm not an expert, but my understanding is that the whole X11 is network transparent thing worked great when apps used the X11 drawing primitives. These days a significant number of X11 apps jus…

> my understanding is that the whole X11 is network transparent thing worked great when apps used the X11 drawing primitives. It did. It was awesome to be able to run one of the expensive academic apps from any X terminal on campus. Network security was largely non-existent then, and you could run X apps not just across campus but across the Internet. I remember a really early web page that had a text field (for your…

Completely off-topic, and I wish I could DM You without extra spam here, but great handle. Commodore Business Machines... Ever use a PET? Loved those things.

Re: An X11 apologist tries Wayland

#302

Earlier quoted context omitted.

Using a wayland desktop, remote login into a Linux server, start a graphical text editor like gvim, it fails. This is a very common way to dev on Linux, I too have been doing this daily, and with ssh+X11 it works out of the box. I wonder what is the best way to do this with Wayland. Should I ask an admin to reconfigure the remote server to run a VNC or RDP server, and then use a specific tool to connect? I wonder if…

I do something similar with vim, no gui. I use vim over ssh with tmux. Others I know use vs code with an ssh backend. These two make up the workflow of roughly 60000 Googlers. None of them need X forwarding. Some people may benefit from X forwarding, but the vast majority of Linux users do not.

Same at FB - vscode with ssh backend is the recommendation, ssh+vim works perfectly fine; last time I checked X forwarding did work, but even with a multi-gigabit connection and 20ms latency it was too painful so nobody did that...

Re: An X11 apologist tries Wayland

#303
post #210

Earlier quoted context omitted.

Wat?

Streaming is most sensitive to how much data you can push through the pipe in a given amount of time, not to how long it takes for a question/answer pair to travel between the server and the client. Latency (how long it takes for messages to travel back and forth), which is where X11 over the network has major issue, doesn't matter in the specific case of watching a video. Essentially, once you press 'play', there's…

Yeah, no - X11 forwarding a video is at best "eh" when you're network local, and horrible otherwise. X11 forwarding burns a lot of bandwidth, and even when that bandwidth is available, going over TCP and SSH makes it implicitly quite latency sensitive.

It's not even fair to compare it to waypipe's h264 compressed buffer feeds.

Re: An X11 apologist tries Wayland

#304

From https://wiki.ubuntu.com/Wayland "The X11 protocol was designed around running graphical apps across the network. While some people use this feature, it's far from common. Wayland drops this requirement as a way to greatly simplify its architecture." X client and server are usually the same machine, but they don't have to be. While on the road, you can use your notebook to open a Gimp session on your home machine…

This is a big misunderstanding. Network handling is stripped from the core design, but is very much available on all compositors. The equivalent to X11 forwarding is waypipe[1], which is far superior to X11 forwarding. Rendering happens entirely on the host and clients can therefore use accelerated resources as they wish, and the (accelerated) h264 encoded buffer feeds means much lower network utilization. 1: https:/…

Low network utilization yes and perhaps superior to X11 core protocol, but it doesn't come for free, for example in terms of latency. And what if said app was actually a video player in it own self? Then you get to decode the video on server and re-encode it again for transport, whereas a primitive-centric protocol could allow decoding the original video directly on the client.

The higher the window size the higher the requirements for the encoder (though Waypipe does say "This way, Waypipe can send only the regions of the buffer that have changed relative to the remote copy.", or is it talking about the video encoder?), whereas with primitive-based systems the requirements are only correlated to the amount of changes done on the display—while still allowing to use image or video encoder for tasks better suitable for it.

I just fondly remember the times when (possibly two decades ago) I run

  xlockmore -mode ifs 
at work accidentally from my home computer and it was running fine over the 100Mbit network, so I didn't realize my mistake until coming back from lunch. Basically just a bunch of pixels running around smoothly, but I think it would be quite a quality test for a video encoder..

I understand though that coming up with a great protocol for user-interface primitives would be a research project in its own right, however. Perhaps something based on JavaScript, WASM, or EBPF fragments sent to the client would be a realistic options. Time has certainly gone past the primitives provided by X11.

But I also think that just "forget about it, we'll video stream it" is just giving up on the problem altogether.

Re: An X11 apologist tries Wayland

#305

Earlier quoted context omitted.

I haven't had screen tearing under X.org for more than a decade. Both under NVIDIA and Intel. A nice made-up issue but it's made up.

Ah yes. Issues you don't have don't exist. Especially, with super consistent, trivial, uniform system components like graphics drivers, display servers, and compositors on linux. Famously stable, reliable, and uncomplicated.

NVIDIA:

    Option      "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
Intel, AMD and X.org modeset driver:

    Option      "TearFree" "On"
You can even enable it at runtime:

    $ xrandr --output $output --set TearFree on
Nouveau:

No bloody idea, nouveau is broken. Sorry to break it to you or you're either using NVIDIA binary drivers or buy a different GPU.

The issue does not exist. Period. If you have troubles enabling these options, I'm sorry for you. Linux in 2022 still requires to choose your HW wisely. If you don't like it/have a different PoV, it's not my problem, it is the status quo.

Re: An X11 apologist tries Wayland

#306
post #7

I recently tried switching to Linux with a few different distro's (Ubuntu, Elementary OS, etc.) and use Wayland. The thing that sticks out like a sore thumb to me, and which I've been unable to solve, is that apparently it's not possible to configure trackpad scroll speed. At all. From what I was able to gather, Wayland/libinput say they shouldn't be responsible for handling it and instead window managers should[0][1…

But you can though - https://i.imgur.com/YFiG2kx.png

Re: An X11 apologist tries Wayland

#307
post #102

Earlier quoted context omitted.

Each time I tried running Firefox over ssh with X11 it either lagged or crashed. With Wayland's Waypipe it works flawlessly, I could even watch a Youtube video through it. I'm double checking it right now using a remove machine a few blocks away from my home. Running `ssh -X remote firefox` lags a lot worse than `waypipe ssh remote firefox`. The latter feels almost native, very responsive. So no, I don't think we are…

> I could even watch a Youtube video through it. Watching a Youtube video on remote X is rarely a problem, there's no latency involved.

Problem is horrible lags, and I mean just program working bad, not latency. I tried doing it with X11 now, and I gave up before I could even type "youtube" to address bar. Then I tried doing

  ssh -X remote firefox https://www.youtube.com/watch?v=XqZsoesa55w
and it wasn't better. I saw the new firefox window, but it stayed unresponsive.

And I bet part of the problem is due to Youtube (and browser generally) involving some non-trivial drawing technologies, rendering a video is not like showing a GTK interface.

Re: An X11 apologist tries Wayland

#308
post #181

Earlier quoted context omitted.

> It is Gtk and Qt that for wahtever reason decided to ditch their Xrender backends. It was often slower and more likely to run in to driver issues than just doing software rendering and sending pixmaps. They're now moving to GL and Vulkan because they can be faster and while they have the same risk of driver issues at least that's the same stack used for video games and CAD and such so more people care about it work…

> It was often slower Any data on this? I can remember that your typical Cairo backend ran much faster on a PC from 2004 than todays GNOME/Gtk runs on current machines. If performance is your only argument you clearly lose with the modern GNOME/KDE + wayland stack. The only way you could make GLAMOR accelerated Xrender faster is by putting the spline tesselation step into a shader. (This was not possible when Xrender…

This. I remember KDE3 being fast as hell doing 2D with a GeForce2 MX, much faster than a Geforce 8200 trying to run a similar rendered desktop but with OpenGL doing Xrender's job.

Re: An X11 apologist tries Wayland

#309
post #274

Earlier quoted context omitted.

What they meant is having thumbnail instead of the icon, so that you can quickly see a preview of all the files instead of having to select them one by one. This article was somewhat recently shared and it explains the whole ordeal https://jayfax.neocities.org/mediocrity/gnome-has-no-thumbna... (contains snarky language). It’s a small(-ish) issue but people often share it as a good example of their frustration with t…

I have had success getting typeahead search working again in some applications with https://github.com/lah7/gtk3-classic .

Well, I switched to Nemo to fix that problem.

Re: An X11 apologist tries Wayland

#310
post #299
post #209

Earlier quoted context omitted.

The roles of client and server being force-swapped is another perhaps unfortunate development.

Why? I think who should be client and who should be server is entirely context/application specific. Sometimes I want to be able to connect to a server from any random client and continue the session.

Because now you never know which is which without a separate explanation. Might just as well call them A and B.
Post reply on HN