Live data from Hacker News

An X11 apologist tries Wayland

artemis.sh

431–440 of 453 posts

Re: An X11 apologist tries Wayland

#431

Earlier quoted context omitted.

Half of the time I want to press right-click or even left-click on the touch pad it actually registers as middle-click which is very annoying as it means a window gets closed rather than focussed; don't want middle-click at all. Undesired Middle-click-paste also happens a lot. When I click a link from Thunderbird (weirdly as it sounds when Thunderbird is a Mozilla app) it opens chromium; dialog to set FF as default d…

> Half of the time I want to press right-click or even left-click on the > touch pad it actually registers as middle-click Are you sure that's not a hardware issue? This doesn't happen in other OSes on the same hardware?

Thanks for these helpful comments guys!

I guess I can remap middle-click to left-click using the wayland equivalent of xinput from a shell script or something. The apparent-FF-crash story described by johnmaguire and eddyb sounds very much like another thing I believe is happening on my notebook. Between these fuckups and the general alienation going on in Linux land (wayland, snaps/flatpack, systemd) I've got to say I'm not enthusiastic to go through those chores and teething probs just to get the same-old gui apps like Inkscape and GIMP (plus FF/Thunderbird) running, so right now I'm leaning to go back to Mac OS more than ever (used Mac OS on and off from 2003 to 2016).

Re: An X11 apologist tries Wayland

#432

Earlier quoted context omitted.

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. P…

Those settings cause absolutely terrible latency and stutter on my system.

I've used these settings with four different Intel iGPUs and a single AMD GPU, and I've not experienced "terrible latency and stutter".

Your report is not widely shared on the Internet either. Arch Wiki, unix.stackexchange.com, r/Linux, and others - none of them confirm it either.

I'm almost sure it's down to your particular HW configuration.

Re: An X11 apologist tries Wayland

#433
post #185
post #166

Earlier quoted context omitted.

I think one thing that sort of disappeared was the vision of thin clients everywhere. X11 is an obvious thin-client solution. Thin client for home use seems like a winning proposition. Rather than giving the kids a Raspberry Pi 400 or garage-sale P4 when they want their own computer, you could hook up another X terminal to a large shared Ryzen box. The hardware gets more efficiently used, files can easily be shared a…

I think quite the opposite happened, just not on X11 level. The web browser is essentially a thin client nowadays. The fact that you have full client-side scripting is one thing that was IMHO a bit underdeveloped in classical thin-client systems because with that you can mask network latency much easier (though, admitted, I don't know a lot about how X11 handles this).

Don't agree at all. The web browser is essentially a standardized computer on which to run your fat client systems like SPAs. The browser can run arbitrary computation locally.

Re: An X11 apologist tries Wayland

#434
post #166
post #141

Earlier quoted context omitted.

This isn't quite right. Both have gotten arbitrarily faster. That some folks have gigabit fiber is proof of that. Graphics have just outpaced networking. Easily.

I think one thing that sort of disappeared was the vision of thin clients everywhere. X11 is an obvious thin-client solution. Thin client for home use seems like a winning proposition. Rather than giving the kids a Raspberry Pi 400 or garage-sale P4 when they want their own computer, you could hook up another X terminal to a large shared Ryzen box. The hardware gets more efficiently used, files can easily be shared a…

The problem being that X thin clients back then were more powerful than desktop PCs at the time. Even now they're more expensive than a Raspberry Pi, so it's more economically efficient to buy one of those.

Re: An X11 apologist tries Wayland

#435

I've tried to use Sway a number of times, and the biggest reason I keep bouncing off it is environment variables. There's a bunch of environment variables I want set for every process in my desktop session, from basic things like $EDITOR and $LD_LIBRARY_PATH to more complex things like $MOZ_USE_XINPUT2 or $SSH_AUTH_SOCK. When I use i3 under X11, gdm runs my ~/.profile script so I get all my standard login environment…

Same here. I also use i3 in a non-standard way: in KDE but with i3 instead of Kwin, and it has been the dream setup for me navigation wise. I wished I could somehow do the same with Sway under Wayland, But that doesn't seem to be supported.

Re: An X11 apologist tries Wayland

#436
post #435

I've tried to use Sway a number of times, and the biggest reason I keep bouncing off it is environment variables. There's a bunch of environment variables I want set for every process in my desktop session, from basic things like $EDITOR and $LD_LIBRARY_PATH to more complex things like $MOZ_USE_XINPUT2 or $SSH_AUTH_SOCK. When I use i3 under X11, gdm runs my ~/.profile script so I get all my standard login environment…

Same here. I also use i3 in a non-standard way: in KDE but with i3 instead of Kwin, and it has been the dream setup for me navigation wise. I wished I could somehow do the same with Sway under Wayland, But that doesn't seem to be supported.

Yeah, I've got a lovely GNOME+i3 setup that I really like. There doesn't seem to be an equivalent for Sway, but the GNOME services get more memory-hungry over time so I'm always looking to see about Sway becoming more usable.

Re: An X11 apologist tries Wayland

#437
post #154

Earlier quoted context omitted.

On the other hand, this works increasingly poorly as most desktop environments and software assumes there is no network involved (for example, last time I tried running Firefox over a forwarded X session I got a bunch of errors about a broken GL context). And you can do the same thing, with usually better results, by using VNC instead (and there are indeed VNC servers for Wayland, for example wayvnc).

Just had to use Firefox remotely (to use WeTransfer to ship a giant file, they dropped support for their cli, grr), and had exactly this issue - it works incredibly slowly over X over SSH. In the end had to use vnc over SSH. (Note that tightvncserver seems to silently ignore the -localhost option now, which means it's completely insecure to run on an internet connected machine. Tigervnc still has the option)

The issue is the new webrenderer or how it is called. There are options in about:config to disable it and force the old webrenderer.

Then it can runs rather fast on X over SSH in LAN and somewhat okayish through the internet.

Ten years ago I was using it all the time and it was very fast over the internet and perhaps even through Tor. I do not know how they could mess it up so badly

Re: An X11 apologist tries Wayland

#438
post #102

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…

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…

The issue is the new webrenderer or how it is called. There are options in about:config to disable it and force the old webrenderer.

Then it can runs rather fast on X over SSH in LAN and somewhat okayish through the internet.

Ten years ago I was using it all the time and it was very fast over the internet and perhaps even through Tor. I do not know how they could mess it up so badly

Re: An X11 apologist tries Wayland

#439
post #403

Earlier quoted context omitted.

> Low network utilization yes and perhaps superior to X11 core protocol, but it doesn't come for free, for example in terms of latency. You can have your cake and eat it too: You can disable the compression if it's a problem. It's highly configurable if you want to play with it. The compression means trading a little bit of hardware resources at either end for a better UX (lower latency, higher throughput). > The hig…

> You can have your cake and eat it too: You can disable the compression if it's a problem. It's highly configurable if you want to play with it. Well you've of course lost the game at that point if your surface is very tiny, given you have no primitives to express "write text hello at x, y" e.g. for a terminal; without compression the bitmap presentation of a terminal—or a text document—is very large. Scrolling will…

The X11 draw APIs are not really used outside stuff written in Motif or hand-written X11 clients like st. Instead, modern X11 clients sidestep all this for performance reasons and render on their own and post buffers (e.g. GLX, cairo, vulkan, whatever they may like). This means copying bitmaps when forwarding, over a protocol that is not made for doing so efficiently.

Sure, if an application is just rendering nothing but text through X (and not using e.g. pango rendering to a cairo context), and you do not prefer using the resources on the machine running the application rather than the one displaying it, and you don't care about performance when using the application locally, then X11's might be more efficient. But for a purely text application, SSH puts X11 and Wayland to shame.

Re: encoder limits, Intel Quick Sync (built into Intel CPUs since 2011) documentation suggests the only limitation there with respect to parallel encoding is whether or not you can keep up with frame-rate requirements - an old example being 10 streams at full HD 30fps. I believe waypipe only focuses on video-memory buffers right now for video encoding right now as a simple heuristic, as CPU memory (shm buffers) are only used for "low performance" content on Wayland.

> I think the bad performance of many X11 apps is not inherent to the protocol but inherent to the programs written in synchronous style ... And this kind of code is possibly so common because doing everything asynchronously can be tedious, and even more tedious in some enviroments such as C.

I believe even libxcb has forced synchronous parts, which are annoying Wayland compositor developers a lot as Xwayland-supporting compositors need a bit of X11 WM code.

The Wayland protocol is asynchronous by nature, and the primary client and server library exposes this with no synchronous pretenses in idiomatic C. Every function you call only queues a request that will be sent when your event loop dispatches next time, and when you receive events your event loop will fire callbacks in bulk.

Nothing is synchronous, and updating your window requires no wait. In the simple case, the only message you'll get back at some point is one informing you that the previous buffer can now be reused (buffer release).

Re: An X11 apologist tries Wayland

#440
post #128

Earlier quoted context omitted.

GNOME has kind of always been on the opposite end of the configurability spectrum from KDE, IME. But also I'm not super clear on how libinput fits into the picture, I think there used to be some Synaptics-specific integration in certain places that I never went back to, to confirm the differences (switched to libinput several years before, and I've completely forgotten since what I was trying to solve back then). Any…

So what are you using or recommending? Recently switched to kubuntu from gnome-ubuntu, and while some pain points have gone away (lack of global menu can partially be kindof mitigated, didn't have to fiddle with touch acceleration like on 20.04), I'm not impressed: middle-click gets in the way a lot and can't be switched off, power mgmt tray is lagging badly behind power events, weird dock preview and not-so-great ap…

FF crashing

(note that the preferred abbreviation is Fx, not FF)

Firefox tends to very much like its shared memory buffers and crashes with SIGBUS if they run out: https://bugzilla.mozilla.org/show_bug.cgi?id=1245239

How much shm is enough depends on both the browser's rendering engine and the display engine, but apparently 1.5GB shm use isn't out of the ordinary. You won't find any references to shared memory (or even general out of memory messages) if Firefox crashes in this way, so it's just another thing to keep an eye on.

Post reply on HN