Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active Nov 21, 2020
Embed
What would you like to do?
Think twice before abandoning Xorg. Wayland breaks everything!

Think twice before abandoning Xorg. Wayland breaks everything!

tl;dr: Wayland is not ready as a 1:1 compatible Xorg replacement just yet, and maybe never will. Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better of not using Wayland at this point.

Wayland solves no issues I have but breaks almost everything I need. And usually it stays broken, because the Wayland folks only seem to care about Gnome, and alienating everyone else in the process. DO NOT INSTALL WAYLAND! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Please add more examples to the list.

Wayland breaks screen recording applications

  • https://github.com/MaartenBaert/ssr/issues/431 broken since 24 Jan 2016, no resolution ("I guess they use a non-standard GNOME interface for this")
  • https://github.com/mhsabbagh/green-recorder ("I am no longer interested in working with things like ffmpeg/wayland/GNOME's screencaster or solving the issues related to them or why they don't work")
  • https://github.com/vkohaupt/vokoscreenNG/issues/51 broken since at least 7 Mar 2020. ("I have now decided that there will be no Wayland support for the time being. Reason, there is no budget for it. Let's see how it looks in a year or two.") - This is the key problem. Wayland breaks everything and then expects others to fix the wreckage it caused on their own expense.
  • https://github.com/obsproject/obs-studio/issues/2471 broken since at least 7 Mar 2020. ("Wayland is unsupported at this time", "There isn't really something that can just be easily changed. Wayland provides no capture APIs")
  • There is a workaround for OBS Studio that requires a obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)

Wayland breaks screen sharing applications

Wayland breaks Gnome-Global-AppMenu (global menus for Gnome)

Wayland broke global menus with KDE platformplugin

Wayland breaks global menus with non-KDE Qt platformplugins

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

  • https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/ broke AppImages that don't ship a special Wayland Qt plugin. "This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session." However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Wayland breaks Redshift

Wayland does not work for Xfce?

See below.

Wayland does not work properly on NVidia hardware?

See below.

References

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Oct 29, 2020

Still less breakage than AppImages.

If you don't want to help the good people finishing the Wayland transition the least you could do is stop yelling at the cloud.

References: an YouTuber
LMAO

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Oct 29, 2020

Err. What? I don't want Wayland. I want Xorg. But thanks for your comment.

And I am not "yelling" but collecting examples with concrete links so that the Wayland developers can help fix the application they broke. But please without introducing even more Red Hat dependencies.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Oct 30, 2020

What a surprise. Desktop components requiring X do not work on Wayland. It's as if they're different display server protocol🤔

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Oct 30, 2020

Thanks for this constructive solution for all the breakage @snakedye.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Oct 30, 2020

Maybe you should also boycott Linux for breaking Windows and Mac software.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Oct 30, 2020

Linux/Unix GUI software was written for X.

@strycore

This comment has been minimized.

Copy link

@strycore strycore commented Oct 31, 2020

"It is true that Wayland somewhat sucks ass" -- The Lutris founder

@strycore

This comment has been minimized.

Copy link

@strycore strycore commented Oct 31, 2020

Here's a fun one: There's no available Python API for getting screen modes / changing resolutions in Wayland. There is one specific to Mutter (Gnome). It's packaged in a non-production ready library called libgnomedesktop which caused a bunch of people to think that I was making the whole Gnome desktop a dependency of Lutris.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Oct 31, 2020

I'll word differently. The premise of this elaborated is shitpost is factually incorrect. You cannot break something that never worked or wasn't design for that platform. Linux doesn't break Windows executable and Wayland doesn't break software made for X.

You are basically complaining Wayland isn't X. Not that Wayland is bad. You've never given any specific reason as to why you though it was an inferior protocol. Expect maybe if you think X is the holy grail.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Oct 31, 2020

Claiming "the future is Wayland", "Xorg is abandonware", various dubious "security" reasons, it seems like Wayland folks would like to see Wayland become the successor of, not an optional alternative to, Xorg. Hence I expect it to be 100% compatible to existing applications, because I doubt that the Wayland developers have the resources to work with each and every application to fix the breakage they caused. If Wayland intentionally wants to be different and break things, they cannot assume everyone will say "great, let me invest time and money to chnage my otherwise perfectly fine application", especially if doing so would mean that the result only would work properly on Gnome (and maybe KDE) who have heavily bought into the Red Hat stack.

At the very minimum, Wayland should get an opt-out compatibility layer that would let existing applications continue to work unchanged. People concerned about the type of "security" Wayland claims could choose to harden their computers by forgoing to run existing applications, and disable that compatibility layer.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Oct 31, 2020

Claiming "the future is Wayland", "Xorg is abandonware", various dubious "security" reasons, it seems like Wayland folks would like to see Wayland become the successor of, not an optional alternative to, Xorg. Hence I expect it to be 100% compatible to existing applications

Your expectations are deeply flawed. x86 replaced Power PC but that doesn't mean x86 is 100% natively compatible with Power PC. They're completely different architectures.

Obviously application interacting with X do not work on Wayland. It's so pedantic I shouldn't even need to mention it. Just like you don't run 32 bits applications on 64 bits libraries.

they cannot assume everyone will say "great, let me invest time and money to chnage my otherwise perfectly fine application"

facepalm.

Your application works fine but it requires an archaic component that bottleneck development on Linux, the entire graphical stack in particular. In your fantasy world, we would all be using 32 bits computers because "apps worked perfectly fine" on 32 bits.

especially if doing so would mean that the result only would work properly on Gnome (and maybe KDE)

That's actually a valid criticism but I might take it more seriously if you didn't linked issues that were solved by standards. Things like xdg-desktop-portal and pipewire solve screensharing and video recording on all Wayland compositors.

At the very minimum, Wayland should get an opt-out compatibility layer that would let existing applications continue to work unchanged.

Xwayland.

@DragonSWDev

This comment has been minimized.

Copy link

@DragonSWDev DragonSWDev commented Oct 31, 2020

"Wayland should get an opt-out compatibility layer that would let existing applications continue to work unchanged"

Wasn't Xwayland made for that? Yes, it's an Xorg Server modified to run as Wayland client but it's impossible to make better solution. Wayland is not Xorg replacement and X11 applications can't work natively with it due to fundamental reasons. X11 applications need X11 server to run and it's not only true for Wayland but for any operating system with different window system. You also need X11 server on Windows or macOS to run X11 applications even if they are natively compiled for these operating systems.

@adnan449

This comment has been minimized.

Copy link

@adnan449 adnan449 commented Nov 1, 2020

Shouldn't you be more concerned about Appimages instead? Last I checked, it doesn't work on Manjaro KDE live. But anyways I don't think you are in position to tell me not to install Wayland. It comes on Fedora by default and I really don't see any reason to change the session.

Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Funny you should say that. I hate to break it to you, buddy, but Linux is a Red Hat product. RH is one of the biggest contributors to upstream Linux and Linux desktop development. "Avoiding glib" is nothing more a fashion statement. Let's not waste anybody's time there.

Wayland breaks screen recording applications

Works on my machine

Wayland breaks global menus in Gnome

GNOME has no global menu.

Wayland breaks screen sharing applications

https://flathub.org/apps/details/us.zoom.Zoom

Wayland broke global menus with KDE platformplugin

KDE bug. How cliche.

Wayland breaks global menus with non-KDE Qt platformplugins

Another KDE bug.

breaks AppImage

AppImages are not relevant. Most of the times it doesn't even work. So much for the "one click" experience.

Looks like 100% of your problems do not exist if you are using the default Linux Desktop Environment (aka GNOME). Don't blame GNOME for other hobby desktops not being able to catch up.

I understand it's your strategy to stir some pointless arguments online to market Appimages, but do understand that there are other strategies that could yield the same outcome.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 1, 2020

It comes on Fedora by default

This alone would be reason enough for me not to touch Fedora.

Besides, most application software gets tested on and optimized for Ubuntu, and hence may or may not run properly on Fedora. For example, we test all AppImages on Ubuntu to make sure they run well there.

Linux is a Red Hat product

Hahaha, nice try. A random user who does not have a single public repository on GitHub tells people obvious BS like this.

GNOME has no global menu

This alone would be reason enough for me not to touch Gnome.

https://flathub.org/apps/details/us.zoom.Zoom

Flathub. More Red Hat. See? This is what I find so utterly annoying. I complain about Wayland, and people push another Red Hat technology as the "answer", Flathub. It requires Flatpak. This alone would be reason enough for me not to touch Flathub.

AppImages are not relevant.

AppImages are super relevant for me. ALL applications I run are AppImages. I don't run any applications that are not AppImages.

Most of the times it doesn't even work.

Maybe you are running a distribution that is not 100% binary compatible with Ubuntu.

the default Linux Desktop Environment (aka GNOME).

The "default" of what? "Linux" has no "default" Desktop Environment.
And if Gnome would become the default Desktop Environment for Linux, this alone would be reason enough for me not to touch Linux on the desktop anymore. Luckily, it isn't. And from what I can see many people prefer Xfce, MATE, and similar desktops.

I understand it's your strategy to stir some pointless arguments online to market Appimages

Then you understand wrong. This post is about Wayland and that it breaks existing software. And worse, that it assumes that application authors are willing to put work into their existing applications just because Wayland is now being pushed by some. My example shows that application authors are fed up with this.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 2, 2020

@HolyStephano

This comment has been minimized.

Copy link

@HolyStephano HolyStephano commented Nov 3, 2020

Nearly all of these issues seem to be focused around missing features.

Primarily on the topic of screen sharing/recording, protocols exist for these outside of the base wayland spec (see wlroots dmabuf and screencopy, and a relevant obs plugin for this) and as much as they aren't "standard" those protocols have basically stayed as they are. Gnome and KDE have to implement some way of doing these things, and gnome themselves only provide a shitty solution.

The issue isn't Wayland itself at this point. It's really just how young it is compared to xorg. Xorg has had what, nearly 35 years of work put into it? Why are we immediately shutting Wayland out when it's barely had time to stand on its' own?

I've been using Sway personally for quite some time now, and since the first major release, i have had very few issues that i can attribute to wayland alone. I can screen record, take screenshots, stream games, and nothing has broken to the point where i've gone "Yup, this is sway or waylands fault"

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 3, 2020

Gnome and KDE have to implement some way of doing these things

What about non-Gnome, non-KDE?

Why are we immediately shutting Wayland out when it's barely had time to stand on its' own?

The problem is not Wayland per se. It probably has many architectural and technical merits (which I am not talking about). However,

  • It is problematic to see Xorg being talked down before Wayland is mature ("Abandonware")
  • It is problematic to see Wayland already being pushed onto users (Fedora ships it by default, makes people think it is ready for general consumption)
  • It is problematic to expect application authors fix the mess that Wayland creates. Application authors do not appreciate this (see my examples above)
  • It is problematic to favor Gnome (and, to a lesser extent, KDE) over everything else (e.g., on FreeBSD, these environments both are rather niche!)
@HolyStephano

This comment has been minimized.

Copy link

@HolyStephano HolyStephano commented Nov 3, 2020

They can implement wlroots, which is already used by Sway, a (near) full implementation of i3 with wayland support, as well as some other more niche compositors. It may not currently be part of the wayland spec but things like screen recording were never the targets of the initial spec, because it's trying to do away with willy nilly privacy invasions like arbitrary screen recording. Gnome itself at least has a pretty garbage tier screen recording API built into the shell which isn't a good solution to this problem. See the dmabuf and screencopy protocols from wlroots, they're both easy to use from a user-facing perspective (obs plugins, various other program to do it) and work wonderfully.

Edit after your edit

It is problematic to see Xorg being talked down before Wayland is mature ("Abandonware")

But we still need to acknowledge that Xorg in general is a terrible spec and has a LOT of issues.

It is problematic to see Wayland already being pushed onto users (Fedora ships it by default, makes people think it is ready for general consumption)

Fedora ships gnome by default, and just doesn't turn of wayland support. Gnome itself is a perfectly fine DE and even has the patches for nvidia users built in. It might as well be as consumer ready as its' ever been, bearing some minor issues.

It is problematic to expect application authors fix the mess that Wayland creates. Application authors do not appreciate this (see my examples above)

It's a new display server. UI Toolkits and other software is going to have to adapt if they want to stay relevant. This is like saying linux isn't worth developing for because they only write windows code.

It is problematic to favor Gnome (and, to a lesser extent, KDE) over everything else (e.g., on FreeBSD, these environments both are rather niche!)

No one is actually favoring these outside of their own development wheelhouses. KDE was working with some of the wlroots community i believe, but no one is prioritizing them for anything. Gnome themselves have explicitly disregarded any mainstream community work (like wlroots) and kept their environment locked down. I don't see how this argument makes sense.

@EndrII

This comment has been minimized.

Copy link

@EndrII EndrII commented Nov 4, 2020

@probonopd Are you a terrible conservative, instead of taking part in eliminating these shortcomings, you decided to sow discontent and bury Wayland!

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 4, 2020

It breaks my fonts!
I have exactly 100DPI monitor and xrandr --dpi 100x100 in .xsession.
But I couldn't find a solution to do the same on wayland: scale font without interface.

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 4, 2020

Many apps still has no wayland support. Electron based, GIMP. Waylayd is more than 10 years old.

@mikhailnov

This comment has been minimized.

Copy link

@mikhailnov mikhailnov commented Nov 4, 2020

Xdotool does not work on Wayland, it is suggest to run scripts from root to feed needed events to the kernel

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 4, 2020

@Monsterovich

This comment has been minimized.

Copy link

@Monsterovich Monsterovich commented Nov 4, 2020

@ystr

This comment has been minimized.

Copy link

@ystr ystr commented Nov 4, 2020

Wayland breaks graphics tablets. If you have one, xorg is the only option.

@frostworx

This comment has been minimized.

Copy link

@frostworx frostworx commented Nov 4, 2020

Wayland doesn't have xembed protocol support and therefore breaks Tabs in yad
(which prevents my steamtinkerlaunch to work correctly under wayland)

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 4, 2020

Screenshot capturing doesn't work in GIMP.

@XVilka

This comment has been minimized.

Copy link

@XVilka XVilka commented Nov 4, 2020

Xmonad will not work and Waymonad is dead (last commit is 1.5 years ago, nobody accepts pull requests).

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 4, 2020

It's not possible to restart window manager, and window manager becomes Single Point Of Failure: if it crashes all clietns die with it.

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 4, 2020

What about networking, thin clients etc?

@clapbr

This comment has been minimized.

Copy link

@clapbr clapbr commented Nov 4, 2020

Out of all Wayland compositors, VRR/FreeSync only works in sway atm and it's sometimes a flicker-fest.

@clapbr

This comment has been minimized.

Copy link

@clapbr clapbr commented Nov 4, 2020

I'm quadriplegic and accessibility is even worse than X11. Stuff like clicklockd or mousetweaks won't work. Also tried a couple virtual keyboards for wayland and they suck.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Nov 4, 2020

@mikhailnov it still baffles my mind that people find normal to have keylogger not requiring root to run

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Nov 4, 2020

@532910 upstream electron supports wayland and gimp 3.0 runs natively on wayland (gimp-git)

@bernharl

This comment has been minimized.

Copy link

@bernharl bernharl commented Nov 4, 2020

I'll just add some of the main benefits of Wayland to me personally:

Mixed DPI monitor support.

Mixed refresh rate support

Multi monitor VRR (Only supported in Sway at the moment though, coming soon to Gnome)

It seems to me Wayland will be much better for gaming, especially in the future.

To me the only downside is that most games run in Xwayland.

@webknjaz

This comment has been minimized.

Copy link

@webknjaz webknjaz commented Nov 4, 2020

Here's a good response to this rant: https://refi64.com/posts/dont-boycott-wayland.html

@frostworx

This comment has been minimized.

Copy link

@frostworx frostworx commented Nov 4, 2020

IMHO boykotting any opensource software is simply stupid, but not actively collecting open issues to show that the X still is needed and useful. Maybe this is just a failed attempt to counter the recent overdramatized and provocative X-must-die hype.
I'd say let's make the best out of it, now as it has broad attention anyway.

@joelkraehemann

This comment has been minimized.

Copy link

@joelkraehemann joelkraehemann commented Nov 4, 2020

I have never understand why we need yet another windowing system. Instead of fixing Xorg's problems, develop Wayland with even more problems. I would expect this behavior from overambitious newbies and not from a respectable developer.
By the way I use Mate Desktop Environment, the original default desktop of Linux ;-)

I am not expecting anything else than dirty lies from wayland developers.

@nahuelwexd

This comment has been minimized.

Copy link

@nahuelwexd nahuelwexd commented Nov 4, 2020

I have never understand why we need yet another windowing system.

@joelkraehemann Read here :) https://wayland.freedesktop.org/faq.html#heading_toc_j_5

@nahuelwexd

This comment has been minimized.

Copy link

@nahuelwexd nahuelwexd commented Nov 4, 2020

Ah, and for @probonopd, I've seen you on many issues about screen sharing on Wayland. See this answer on one of the issues that you've linked MaartenBaert/ssr#431 (comment)

@joelkraehemann

This comment has been minimized.

Copy link

@joelkraehemann joelkraehemann commented Nov 4, 2020

I have never understand why we need yet another windowing system.

@joelkraehemann Read here :) https://wayland.freedesktop.org/faq.html#heading_toc_j_5

Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland.

Say no to Wayland!

@HolyStephano

This comment has been minimized.

Copy link

@HolyStephano HolyStephano commented Nov 4, 2020

Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland.

It is outside the scope and can be implemented at the compositor level rather than the display protocol level. Sway for example, while not quite the same thing, already supports headless displays and forwarding that display over VNC.

@erm2587

This comment has been minimized.

Copy link

@erm2587 erm2587 commented Nov 4, 2020

I understand it is way easier for you to blame others for innovations that would force you (and the rest of us) to make some extra work, than sitting down and actually doing the job.
I could also boycott the AppImage project for bloating my system with Gigabytes of files that I don't actually need, but I respect the project and the work that is being done to keep it working. If you don't like Wayland, don't use it, don't support it in your software and let time tell if you are right or not.

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 5, 2020

Here's a good response to this rant: https://refi64.com/posts/dont-boycott-wayland.html

Nope, nothing's good about it.

  1. Wayland is so barebones it requires a ton of code to implement lots of features which means it's delegated to DEs which have the resources to implement them (Gnome and KDE)
  2. No XEmbed support (goodbye XFCE which is built on top of XEmbed - the settings application and desktop panels)
  3. It makes implementing anything even remotely as effective as RDP impossible, as the compositor works will full frames/rectangles and has no idea what is changing in them and what's not. VNC (which is the only option) has always sucked tremendously.
  4. No graphical output APIs whatsoever. Imagine three different applications using three different graphical toolkits under Wayland. Now imagine you want all these three apps have the same 1) fonts settings and rendering 2) zoom 3) color palette. Looks like there's no option to sync these settings as the wayland compositor does absolutely nothing aside from window management, right?

Let's be honest: Wayland is a thin layer on top of KMS. It's not a graphical server or even a decent graphical protocol as found in X11, Windows, MacOS or Android.

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 5, 2020

I understand it is way easier for you to blame others for innovations that would force you (and the rest of us) to make some extra work, than sitting down and actually doing the job.

Wayland has been peddled as a second coming of Christ, sorry, something which is leaps and bounds better than X11/X.org. Only it's been 12 years. Only it still sucks everywhere outside of Gnome and it's not even fully usable under KDE. How much should we wait for to get something which is not mired in tons of limitations or features working suboptimally?

When you replace something and expect wide acceptance, you don't replace it with something substantially worse which doesn't even work for lots of people.

@JBBgameich

This comment has been minimized.

Copy link

@JBBgameich JBBgameich commented Nov 5, 2020

Re Wayland breaks AppImages: Surprise surprise, Qt applications don't work on Wayland if you don't ship their wayland support parts.

@protonesso

This comment has been minimized.

Copy link

@protonesso protonesso commented Nov 5, 2020

But please without introducing even more Red Hat dependencies.

@probonopd stop using glibc and gcc then

@davidedmundson

This comment has been minimized.

Copy link

@davidedmundson davidedmundson commented Nov 5, 2020

because the Wayland folks only seem to care about Gnome

To clarify those KDE points, I am a lead KDE dev, and the 3 KDE points from Kai's and Martin's blogs are case of you not understanding properly. Especially the appimage one. They need a special XCB plugin to work on X too... the attempt at making a point is very cringeworthy.

Would you mind correcting it?

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 5, 2020

Thanks @davidedmundson for chiming in.

This gist was posted in various places without context. Hence let me clarify: What I am concerned with is that some people push Wayland as a "replacement" for Xorg, when in fact it is not ready as a 1:1 compatible Xorg replacement just yet, and maybe never will.

So it's breaking existing contracts on the desktop, which is what I don't like. I am not disputing that if one adds special work(arounds) for Wayland, one can get things back to a working state. But not all applications I would like to use are willing or knowledgable to put the extra work in. Edited the gist to clarify this.

the 3 KDE points from Kai's and Martin's blogs are case of you not understanding properly

I am happy to learn and correct. Can you explain what exactly I got wrong?

@HolyStephano

This comment has been minimized.

Copy link

@HolyStephano HolyStephano commented Nov 5, 2020

What I am concerned with is that some people push Wayland as a "replacement" for Xorg, when in fact it is not ready as a 1:1 compatible Xorg replacement just yet, and maybe never will.

Why is it hard to not use software you don't like? You don't have to use, or support it, but a replacement to xorg is going to happen whether anyone wants it or not.

People pushing for us to move to wayland makes sense. People use alpha/beta/indev software all the time and we don't just go "this unfinished project isn't finished, therefore the idea behind it is bad." we use beta software to improve it and to improve our own experiences and usecases. Why shouldn't people be trying to use wayland to further the development of it, or to at least understand what the goals are? If wayland isn't the answer, and x isn't the answer, then what is?

No one has anything else other than like, Arcan. Until something else exists, wayland is the only "competitor" that we have to really expand on without hacking more features onto x.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 5, 2020

I will consider it once applications like SSR, Vokoscreen, Jitsi Meet etc. are working without any shenanigans. But their developers have suggested that they cannot or will not make changes on their side.

@DragonSWDev

This comment has been minimized.

Copy link

@DragonSWDev DragonSWDev commented Nov 5, 2020

@birdie-github

Only it's been 12 years.

Wayland was not stable and production ready until 2013 so it's 7 years not 12. Did X11 got all features it has today with first version? Well I don't think so and considering that Xorg is still missing some features should we call it "not ready"?

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 5, 2020

Just found out that it also breaks another application I use regularly, Redshift. Redshift adjusts the color temperature of your screen according to your surroundings. This may help your eyes hurt less if you are working in front of the screen at night.

@bernharl

This comment has been minimized.

Copy link

@bernharl bernharl commented Nov 5, 2020

Just found out that it also breaks another application I use regularly, Redshift. Redshift adjusts the color temperature of your screen according to your surroundings. This may help your eyes hurt less if you are working in front of the screen at night.

Gammastep does the same for Wayland, using it right now.

@nahuelwexd

This comment has been minimized.

Copy link

@nahuelwexd nahuelwexd commented Nov 5, 2020

@probonopd

Wayland breaks Redshift
https://wiki.archlinux.org/index.php/redshift broken ("Redshift does not support Wayland since it offers no way to adjust the color temperature")

Please, if you are going to quote something from the Arch wiki, cite the full information, not just the part that favors your tabloid gist :)

Screenshot_20201105-172618~2

https://wiki.archlinux.org/index.php/Backlight#Wayland

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 5, 2020

Wayland was not stable and production ready until 2013 so it's 7 years not 12. Did X11 got all features it has today with first version? Well I don't think so and considering that Xorg is still missing some features should we call it "not ready"?

7 years and we're still struggling with basic features while other features are near impossible to implement effectively because Wayland is so ... simple? No one needs "simple", people need to have their work done. X.org just works. Wayland just doesn't work unless you want to severely limit yourself in terms of what you can do under it.

And yeah, X.org was developed by a much smaller team with no prior experience, with no prior work to look at, and they still made something feature-rich very fast.

@mikhailnov

This comment has been minimized.

Copy link

@mikhailnov mikhailnov commented Nov 5, 2020

@erm2587

This comment has been minimized.

Copy link

@erm2587 erm2587 commented Nov 5, 2020

Wayland has been peddled as a second coming of Christ, sorry, something which is leaps and bounds better than X11/X.org. Only it's been 12 years. Only it still sucks everywhere outside of Gnome and it's not even fully usable under KDE. How much should we wait for to get something which is not mired in tons of limitations or features working suboptimally?

Just don't wait! What are you doing waiting for a project you don't like? Don't use it! Do not even waste your time and energy complaining about how bad it is! If it is actually as terrible as you are saying, it will just die by it self. Otherwise you'll be proved to wrong. Then you may admit it or not, but it is as simple as that.

Even if Wayland reaches the point where it becomes a standard, you don't have to worry, all the heaters will expend a lot of their time and energy maintaining X11 based distributions for those who don't want to accept Wayland.

@mikhailnov

This comment has been minimized.

Copy link

@mikhailnov mikhailnov commented Nov 5, 2020

@rafaelmardojai

This comment has been minimized.

Copy link

@rafaelmardojai rafaelmardojai commented Nov 5, 2020

Thanks for the comedy gist, very funny.

Now go ahead and maintain Xorg yourself.

@mikhailnov

This comment has been minimized.

Copy link

@mikhailnov mikhailnov commented Nov 5, 2020

Nibody wrote about wine. Wine develeopers wrote that wine cannot be ported to wayland because of inability to get coordinates of the window. I find this inability mobile-friendly, but not desktop or laptop friendly.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Nov 5, 2020

@mikhailnov

Of course I fo not find it normal, but I find inability to use my computer much less normal

Is your computer xdotool?

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Nov 5, 2020

Even if Wayland reaches the point where it becomes a standard, you don't have to worry, all the heaters will expend a lot of their time and energy maintaining X11 based distributions for those who don't want to accept Wayland.

If anyone was still willing to maintain X and had the ability to do so, they would have committed something in the past 2 years. Development has been stale for a while and is practically dead at this point. I don't think everyone should just jump to Wayland. If something doesn't work for you on Wayland, use X in the meanwhile but it's delusional to entertain the possibility X still has decades ahead. If you don't like Wayland you are free to develop your own display server protocol but I seriously doubt it'll have any form of adoption.

The faster people accept the fatality that X is either dead or dying, the faster we can move on.

@davidedmundson

This comment has been minimized.

Copy link

@davidedmundson davidedmundson commented Nov 5, 2020

I am happy to learn and correct. Can you explain what exactly I got wrong?

I am happy to help explain things if it helps results in some clarifications.

In general we're mixing up "does this X specific things work" and "is there a way to do feature Y".

No-one has ever claimed X specific things will directly work as is. This gist (which in fairness maybe I have been linked to out of context) conflates those two sentences and presents them as one. Stating their is no way to do a feature is valid, but that's not what this post does.

But to go through the KDE side specifically:

Wayland broke global menus with KDE platformplugin

Xorg server doesn't natively support global menus either. There is KDE code on top writing into arbitrary X atoms. Effectively we made an X specific "protocol". It is true that we have to write a wayland specific protocol to do the same. We (KDE) did so. What's the supposed story?

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

X breaks AppImages that don't ship a special XCB Qt Plugin. So it's a stretch to make a point there.

That blog is also specifically about setting an environment variable to tell it to use a specific plugin AND not having a plugin causes a problem It was plasma setting that variable, it no longer does since 4 years or so! That was Plasma/Qt at fault not anything else. AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 5, 2020

@probonopd, I think you missed about 50 years of computer history. Things never worked the way you propose in the UNIX camp.

It seems that popularity brought this comercially-biased mentality about ABIs, but sadly without any money to back it up, and I don't think it's going to work this way... but we all do try to keep compatibility when it makes sense.

And let's all remember that Wayland didn't come out of another dimension, you're bashing the same people that gave you X11 in the first place.

@birdie-github: X11 was a quick project? I invite you to take a look at X11 from 20 years ago, same base protocol and everything yet 90% of what you take for granted didn't exist back then, and it could be already considered quite mature at that stage.

@gonzaarcr

This comment has been minimized.

Copy link

@gonzaarcr gonzaarcr commented Nov 6, 2020

GNOME has global menu, and it works on wayland, except for keyboard shortcuts (as any global shortcut in wayland)

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 6, 2020

Thanks for the clarifications @davidedmundson. My main criticism is that Wayland breaks existing applications unless the applications are specifically changed for Wayland. I understand that this is by design, and I prefer to avoid anything that breaks decade-long contracts one was factually supposed to be able to rely on. Looks like I value long-term binary compatibility much more highly than some. Possibly distributions could mitigate this at least to some extent by making xwayland the default, although this would probably take away the advertised security improvements that are supposed to come with Wayland.

AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode.

That's good news then. Correcting it above. I hope xwayland mode will not go away anytime soon.

As for the global menus, why doesn't KDE then currently use the com.canonical.AppMenu.Registrar standard without any modifications?

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 6, 2020

Thanks @gonzaarcr. Corrected above to say it broke Gnome-Global-AppMenu specifically. Glad to hear that there are other similar solutions.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 6, 2020

@snakedye

If anyone was still willing to maintain X and had the ability to do so, they would have committed something in the past 2 years.

Have you considered it may be possible that it is feature complete and there is no need to change much anymore? Some people call this "mature", marketing people may even call this "enterprise grade".

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 6, 2020

@nahuelwexd what you link proves the point:

  • It breaks the core redshift functionality, which is changing the color temperature gradually while it is running
  • Only partial, desktop environment specific replacements exist, and once again, only Gnome and KDE (plus one I have never even heard of) are even mentioned

That does not help those who run neither.

@bernharl

This comment has been minimized.

Copy link

@bernharl bernharl commented Nov 6, 2020

@snakedye

If anyone was still willing to maintain X and had the ability to do so, they would have committed something in the past 2 years.

Have you considered it may be possible that it is feature complete and there is no need to change much anymore? Some people call this "mature", marketing people may even call this "enterprise grade".

That definitely is not true given today's mixed dpi and mixed refresh rate support in Xorg.

@refi64

This comment has been minimized.

Copy link

@refi64 refi64 commented Nov 6, 2020

@birdie-github article author, I'm really confused as to why the points you mentioned disprove it because they uhh have nothing to do with the article, but anyway:

Wayland is so barebones it requires a ton of code to implement lots of features which means it's delegated to DEs which have the resources to implement them (Gnome and KDE)

Sway exists and is independently developed, and libweston & wlroots are available to assist with compositor development, with the latter already enjoying quite a bit of usage, e.g. with Wayfire.

No XEmbed support (goodbye XFCE which is built on top of XEmbed - the settings application and desktop panels)

You could still create a nested GL surface and render into it, it would just require some extra code modification.

It makes implementing anything even remotely as effective as RDP impossible, as the compositor works will full frames/rectangles and has no idea what is changing in them and what's not. VNC (which is the only option) has always sucked tremendously.

The Wayland spec is intentionally network-agnostic, but there's no reason a compositor that can send messages over a network can't exist, and indeed one does.

RDP sends bitmap images of the remote system, so I'm not sure what extra efficiency you're referring to there.

No graphical output APIs whatsoever. Imagine three different applications using three different graphical toolkits under Wayland. Now imagine you want all these three apps have the same 1) fonts settings and rendering 2) zoom 3) color palette. Looks like there's no option to sync these settings as the wayland compositor does absolutely nothing aside from window management, right?

Almost no one uses Xorg's graphical APIs because they're pretty terrible. The stark majority of Linux apps are GTK and Qt, both or which do all their own rendering.

Fonts are already shared across GUI toolkits via fontconfig, and again almost nothing uses Xorg drawing APIs, including the font ones.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Nov 6, 2020

@snakedye

If anyone was still willing to maintain X and had the ability to do so, they would have committed something in the past 2 years.

Have you considered it may be possible that it is feature complete and there is no need to change much anymore? Some people call this "mature", marketing people may even call this "enterprise grade".

Some would also call it outdated. If X is features complete, that means it'll never be compatible with future display technologies. It already isn't with modern ones.

@mikhailnov

This comment has been minimized.

Copy link

@mikhailnov mikhailnov commented Nov 6, 2020

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 6, 2020

I'll try once again: I'm using module-x11-bell which replaces the terrible pcspeaker "beep" with a nice "bubble" sample.

All terminals, firefox and other programs nicely notify me of their events.

Is there a some alternative for wayland?

@bodqhrohro

This comment has been minimized.

Copy link

@bodqhrohro bodqhrohro commented Nov 7, 2020

LoLoSwitcher is in no way eligible for porting on Wayland for now. Actually, there is no way to make compositor-independent layout switchers yet, not even mentioning that advanced ones.

I've already listed lots of things that "just work" with X11, and which Wayland lacks, in WineHQ bugtracker, there barely is more to be added ;)

I put a lot of hope into the wlr-foreign-toplevel-management, which solves one of the most important problems of Wayland, introduced intentionally and ideologically: the inability of Wayland clients to know about each other in a generic way. This extension makes things like independent taskbars, docks, full-pledged analogs of wmctrl/xdotool/rofi, and so on, possible. KDE folks will likely follow it, as the same functionality is required for KWindowSystem (the current Wayland implementation of it is a no-op stub), and thus for applications that rely on it, like Latte-Dock.

But I'm really afraid that GNOME developers will ideologically reject wlr-foreign-toplevel-management or any analogs, just like they rejected SSD. Which means that some proprietary software that targets the mainstream Ubuntu/Fedora desktop (which is going to be GNOME on Wayland, unfortunately) may drop support for GNU/Linux, as the key functionality can't work on this platform anymore. This is especially crucial for the users of time trackers (please don't start yet another tracking-employees-is-evil holywar here), as time trackers rely on the ability to track the active window. Dropping support for GNOME===GNU/Linux in time trackers will make these employees/contractors have to choose between migrating on Windows/macOS, even if they use a compositor that technically supports tracking the windows, or losing the job. A really terrible perspective, especially if regarding the growing demand in remote work nowadays.

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 7, 2020

@bodqhrohro There is a backend dbus API for this in gnome shell, but it's not exposed by default for security reasons. There was talk of adding this to the portal and it stalled due to lack of a good way to design it: flatpak/xdg-desktop-portal#304

It's unlikely GNOME developers would want to implement such a wayland protocol without some kind of security policy on it.

@refi64

This comment has been minimized.

Copy link

@refi64 refi64 commented Nov 7, 2020

@bodqhrohro it's entirely possible to control keyboard layouts without depend on Xorg or Wayland, see kmonad for an example of an advanced layout manager that does this.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 7, 2020

@bodqhrohro for most software developers it will never be a priority to support closed-source applications, it's up to those companies to work on whatever changes and standards they need to make their applications work, or at least someone who cares about closed-source applications.

The problem with some extensions is that they mean the session can be compromised by unprivileged applications, and that I guess nobody wants, so until there's a solution everyone has to be patient.

OTOH, it may take some effort, but it's a realistic goal to revert/correct unreasonable company policies, and in the meanwhile X11 is still there...

@kode54

This comment has been minimized.

Copy link

@kode54 kode54 commented Nov 7, 2020

I have never understand why we need yet another windowing system.

@joelkraehemann Read here :) https://wayland.freedesktop.org/faq.html#heading_toc_j_5

Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland.

Say no to Wayland!

And for Network Transparency, there's already a project in development that apparently works quite well, Waypipe.

It currently needs to be installed on both client and server machines, and pipes itself over an SSH session, and pipes one or more Wayland apps from the remote machine onto your local Wayland session. Quite similar to X forwarding.

I can't actually say how well it works, though, since I don't actually have a test setup to use it. The only other Unixish machines in my house are running macOS and FreeBSD respectively, so I don't really have any remote Linux machines I'd want to run Wayland apps on. I suppose I could try waypiping the non-KDE version of qdirstat from my dedicated server and see how well that compares to running a forwarded X session.

Anyway...

Yes, I realize that Gnome and KDE are only just the major players, and that support should be available from other desktop environments as well. That is why there is a lot of Wayland work going into the wlroots project, including adoption of newer protocols, and attempts to get newer protocols merged into the upstream Wayland standard.

wlroots already has Sway as its primary supported compositor, but if you're not of the sort to like tiling window managers, and want an overlapped window manager instead, and also want fancy rendering effects as an option, similar to Compiz, you can use Wayfire, which is semi-mature already, and is fully compatible with almost all of the tooling and utilities that are already written to work under wlroots/sway.

So you can use wf-recorder or wlrobs for screen recording from any of the wlroots compositors, and future compositors can use wlroots to implement any other desktop they want, if Sway or Wayfire are insufficient.

If you want to screen cast from anything that's using Pipewire, there's xdg-desktop-portal-wlr, which is extremely basic right now, but with an as yet unmerged pull request, can also use slurp or a dmenu popup to pick a desktop to record. This works with Firefox with Fedora's patches, and should also work with Chromium. I'm going to guess the above mentioned Zoom screen sharing that works on Gnome also uses Pipewire and xdg desktop portal, as that's the de facto way to do it from Gnome Wayland sessions. I can't speak for any other distribution, but at least on Arch, this Pipewire capture is super fast, even on my 4k display. It has a wacky slow-scanning effect on Fedora Silverblue, and I couldn't even make it work from plain Fedora.

And speaking of slurp, there's its counterpart for image capture, grim, which captures still images from wlroots desktops, or regions of their desktops, which you can command by piping the output from slurp into grim. A default configuration example for Wayfire makes this setup the default shift-printscreen hotkey action.

VRR/Freesync was mentioned above as well. I don't know how well that works under Sway, since it was mentioned as having basic support. I guess this could also be supported by any other wlroots compositor, including Wayfire? I wouldn't mind testing that, especially since VRR/Freesync are broken under Xorg if you have a multi-monitor setup, like I do.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

I sit just me or is there a pattern that goes like this:

<Wayland shortcoming> can be overcome by using <additional software made specifically for Wayland>?

Turning a stack like this:

  • Kernel, Xorg, the application (no Gnome, no KDE needed)

into a stack like this:

  • Kernel, Wayland, a special compositor, Pipewire, Xdg portals (leaning toward Flatpak), the application with special patches for Wayland (works only properly on Gnome and if you are lucky KDE)

Let's keep in mind that outside of the Linux world, Gnome and KDE have a minority "market" share on the desktop:

On "Unix", people like to mix and match components as they see fit for a particular use case.

This is why I am so concerned about Wayland being biased in favor of a particular stack. We don't want all systems to be turned into essentially the Fedora stack. (Nothing against Fedora, but it's not for everyone.)

If Wayland ever wants to replace Xorg, it needs to be agnostic as to the other elements of the stack, rather than biased in favor of an IBM Red Hat centric world view.

@nahuelwexd

This comment has been minimized.

Copy link

@nahuelwexd nahuelwexd commented Nov 8, 2020

@probonopd Wayland as such is agnostic about everything. It was designed to be simple by default and all work to be relegated to compositors, since in X's time the server was acting like a man in the middle, and even hindering certain operations.

And btw: No, in the days of X it wasn't just "kernel, Xorg and application", but rather "kernel, Xorg, 25 extensions for Xorg, compositor and application". In Wayland it's: "kernel, compositor, application". It is THAT simple.

Also, portals are useful for all types of applications, since they're a standardized API that allows application developers not to depend on specific implementations, but rather to be able to be compatible with a multitude of implementations at the same time: For example, to select a file. Many applications need to open the file selector, and it becomes hell when applications open their own file selector instead of opening the system one, since they don't respect any of your settings. An example of this is when you're in Plasma and GTK opens, or when you're on your PinePhone and the file selector that the app opens doesn't fit the screen of your device. Is very annoying. And this is solved using the Flatpak portals (which don't necessarily require Flatpak to be used), since the portal is the one in charge of opening the corresponding file selector in each system, achieving a good user experience.

On wl-roots you don't need PipeWire to record the screen :)

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

And this is solved using the Flatpak portals

Thanks for calling it what it is.

which don't necessarily require Flatpak to be used

Are there any examples of this?

Just proves the point once again: They "solved" a Wayland annoyance for Flatpak but "forgot" to solve it for alternative solutions including, but not limited to, AppImage. This is what I mean with "biased", "forcing the Red Hat stack", "not agnostic".

@nahuelwexd

This comment has been minimized.

Copy link

@nahuelwexd nahuelwexd commented Nov 8, 2020

Are there any examples of this?

@probonopd https://gitlab.gnome.org/-/snippets/19

Run that snippet and voila! you're using a portal without needing to be inside a Flatpak sandbox :)

Yeah, that snippet is tied to PipeWire and GStreamer, but I think that with some modifications you can use it without PipeWire (I'm not too sure)

Portals, while created with Flatpak in mind, are not tied to Flatpak because they're literally pure DBus interfaces, so any application can use them.

Ah, no

They "solved" a Wayland annoyance

The annoyance was resolved for Xorg as well, as you can now use a simple API without worrying about implementation details. You don't need to know any screen recording method in Xorg, just use the portal and you already solve the problem for Xorg and Wayland (in addition to the problem I mentioned in my previous answer)

Oh and by the way, in the free software community, never expect to create a solution that can last forever. You always have to keep improving to stay relevant. See how now Snap is working to implement the portals correctly. Something similar should happen in AppImage, update with better things and stop being a simple compressed file that mounts a temporary folder with a read-only file system. Find a way to have security by default (that applications cannot do and undo with your system at will). Find a way that AppImage can receive security updates on their libraries without the need for the author to send an update. Find a way that AppImages can work on musl systems without the author having to bundle glibc or recompiling the whole app with musl :)

Don't become part of the internet peanut gallery, if you think things can be improved, improve them

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

Yeah, that snippet is tied to PipeWire and GStreamer

And Glib and D-Bus... see? Shoving more Red Hat centric dependencies onto the stack to work around what Xorg could do natively.

@refi64

This comment has been minimized.

Copy link

@refi64 refi64 commented Nov 8, 2020

GStreamer and GLib are not required. You could use the direct pipewire API and whatever main loop & D-Bus library you want. The example likely chose GStreamer&GLib simply because the former is the easiest way to do audio pipelines from Python, and GLib provides a main loop to tie it all together.

@JBBgameich

This comment has been minimized.

Copy link

@JBBgameich JBBgameich commented Nov 8, 2020

which don't necessarily require Flatpak to be used

Are there any examples of this?

Yes, snap also uses them, and on Plasma Mobile all applications use xdg portals. They don't have to do anything special for that, the plasma-integration plugin is able to call the XDG portal. Inside flatpak, applications would use the xdgdesktopportal plugin, which is part of Qt, which does a similar thing. Actually I'm pretty sure AppImages could use that plugin to if there is interest in doing that.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

Actually I'm pretty sure AppImages could use that plugin to if there is interest in doing that.

Is there an example that shows how to use portals without Flatpak nor Snap?
Keep in mind that AppImage does no sandboxing by default, so would it be useful for anything at all?

@davidedmundson

This comment has been minimized.

Copy link

@davidedmundson davidedmundson commented Nov 8, 2020

You didn't correct the above. I do not appreciate having my time wasted.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

In fact I did @davidedmundson:

Regarding

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

I added the following sentence:

However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Regarding

Wayland breaks global menus with non-KDE Qt platformplugins

If I am not mistaken, then global menus in KDE currently only work with QT_QPA_PLATFORMTHEME=kde but not with e.g., QT_QPA_PLATFORMTHEME=qt5ct or the default Qt Unix platform theme, because KDE has introduced _KDE_NET_WM_APPMENU_OBJECT_PATH and _KDE_NET_WM_APPMENU_SERVICE_NAME which did not previously exist. If I am not entirely misreading

Those of you familar with Wayland might notice that it uses global window IDs, which don’t exist in a Wayland world

in https://blog.broulik.de/2016/10/global-menus-returning/, then this was done to work around Wayland. With the result that it "breaks global menus with non-KDE Qt platformplugins".

I'd be thrilled if you could prove me wrong, as this would then solve helloSystem/Menu#12.

@JBBgameich

This comment has been minimized.

Copy link

@JBBgameich JBBgameich commented Nov 8, 2020

Keep in mind that AppImage does no sandboxing by default, so would it be useful for anything at all?

Yeah, you could achieve a native appearance of the file dialogs across different desktop environments. I'm not sure how AppImages currently work. Since they bundle Qt, can they load the native platformtheme at all?

Is there an example that shows how to use portals without Flatpak nor Snap?

As in technical proof that it works without sandboxing, there is Plasma Mobile. In more pracatical terms, there is a simple check in Qt that loads the xdgdesktopportal theme if the enironment variable SNAP is set to 1, or if /.flatpak-info exists. They would probably happily accept a patch to enable it in more environments.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

if the enironment variable SNAP is set to 1, or if /.flatpak-info exists

So it is correct to say that "XDG" desktop portals were developed caring only for Flatpak and Snap? Which would prpove my point: These people simply don't care for anything else. Also, when I google for https://github.com/flatpak/xdg-desktop-portal then the first match is a repository in the Flatpak organization.

@nahuelwexd

This comment has been minimized.

Copy link

@nahuelwexd nahuelwexd commented Nov 8, 2020

To all the people who have wasted their time trying to convince a stubborn man that he's wrong, it's time to stop.

Let's just ignore that this ever happened and get on with our lives, it's not worth continuing. He will simply take your answers, take sentences out of context and use them to his advantage to make everyone believe that he's right.

It's a shame.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

Everyone is welcome to check out the facts for themselves. This is why I am posting links to the stuff that is broken. I'd actually be happy to be proven wrong!

@JBBgameich

This comment has been minimized.

Copy link

@JBBgameich JBBgameich commented Nov 8, 2020

if the enironment variable SNAP is set to 1, or if /.flatpak-info exists

So it is correct to say that "XDG" desktop portals were developed caring only for Flatpak and Snap?

No, that's completely wrong. My statement referred to how its implemented in Qt, not to the portal itself.
XDG portals were developed by the flatpak developers, but with other applications in mind.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 8, 2020

@probonopd times change, Wayland is a good investment, the ecosystem just needs more work, and people would fix their own problems, not yours, isn't that to be expected?

You want them to fix your problems? make the problems theirs somehow.

OTOH, wlroots seems to be a good answer to all the issues you mention. Maybe we need more abstractions around that, and maybe we need more diversity of implementations...

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 8, 2020

@ismail all I am saying is that if you are interested in existing applications to "just work" without the need for adjustments, then you may be better of not using Wayland at this point.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 8, 2020

@probonopd since when people that want things to "just work" made a difference? by definition they aren't getting involved, otherwise we would label them differently, they just demand things screaming to the void.

The majority of people, who also want things to "just work", are lazy enough to not try to switch from a Wayland DE if it's pre-installed, and what do you think will happen when X11 is dropped?

It's coming and developers will have to port their software or face oblivion, but ultimately it's each project's choice.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 9, 2020

It's coming and developers will have to port their software or face oblivion, but ultimately it's each project's choice.

This mindset is unacceptable to me. People can break their own leaf node software all day long, but don't break central pieces of the stack others are depending on. Wayland is breaking other people's spftware and is expecting other people to do extra work.

Wayland DE if it's pre-installed

Hence, we need to ensure it gets pre-installed nowhere (besides Fedora maybe) by pointing out that it is breaking everything.

It's systemd all over again, with the difference that I never had any real technical trouble with systemd but have been running into constant issues with Wayland ever since it entered the scene.

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 9, 2020

@probonopd Unfortunately there is no way forward without breakage and extra work. If the mindset of breakage is unacceptable to you then please help contribute to either X or Wayland. Both have a lot of issues that need work, and contributions to either of them will help the other.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 9, 2020

@HolyStephano

This comment has been minimized.

Copy link

@HolyStephano HolyStephano commented Nov 9, 2020

This mindset is unacceptable to me. People can break their own leaf node software all day long, but don't break central pieces of the stack others are depending on. Wayland is breaking other people's spftware and is expecting other people to do extra work.

And this is who's problem? The developers. You want your software to be used? Port it to the standards in play or bite your tongue because people will adopt a new standard, whether it's wayland or not, and you'll be left in the dust sitting on X. Developers refusing to do work is not an excuse for using a terrible protocol and giving ourselves stockholm syndrome. We complain that some hardware (see: wireless cards from terrible vendors) doesn't properly support linux, and the drivers are bad. Do we blame that on Linux? No, why would we, that's insane. We blame it on the hardware vendor for creating a bad product.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 9, 2020

It's systemd all over again, with the difference that I never had any real technical trouble with systemd but have been running into constant issues with Wayland ever since it entered the scene.

Yet those issues you mentioned so far are corner cases that do have solutions, it's just a matter of time, and we can expect a portable Wayland in the near future; a quite different scenario to the systemd one in every aspect.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 9, 2020

You want your software to be used? Port it to the standards

Full ack. The standard is X11R7.7.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 9, 2020

corner cases

It's what I use every day. So for me it's not "corner cases" but bare essentials.

(In contrast, not once did I have a security incident related to X11, nor did I ever try to combine two monitors with different resolutions. So these things are quite esoteric "corner cases" for me. See? This is very subjective.)

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 9, 2020

There's no denying that Wayland is on it's way to become a de-facto standard soon, so @HolyStephano got a point there.

corner cases

It's what I use every day. So for me it's not "corner cases" but bare essentials.

(In contrast, not once did I have a security incident related to X11, nor did I ever try to combine two monitors with different resolutions. So these things are quite esoteric "corner cases" for me. See? This is very subjective.)

I meant corner cases from an implementation point of view; the basic mechanics are already there, it's just that there's a lot of code missing around some X extensions like xshm, xrandr, etc. If as an application developer you don't do anything about that missing code, you don't get to complain either, and the same goes for ISVs.

@DragonSWDev

This comment has been minimized.

Copy link

@DragonSWDev DragonSWDev commented Nov 10, 2020

@birdie-github

7 years and we're still struggling with basic features while other features are near impossible to implement effectively because Wayland is so ... simple? No one needs "simple", people need to have their work done. X.org just works. Wayland just doesn't work unless you want to severely limit yourself in terms of what you can do under it.

And yeah, X.org was developed by a much smaller team with no prior experience, with no prior work to look at, and they still made something feature-rich very fast.

What basic features? Screen share, screen recording, Remote Desktop, Night Light etc.? It's all working fine on Wayland. What "basic" features are missing? How can you say "X.org just works" when HiDPI support is broken, multi screen is broken, mixed refresh rate doesn't exists at all? User with multi refresh rate screens doesn't want to hear about limitations, he expect things to just work and make his work done. He expect something obvious for macOS or Windows user that X.org still fails to provide after all those years. So this "just works" is basically only your opinion. But Wayland can "just works". I'm using it every day and I'm not missing any "basic" features.

No. X.Org Server took 15 years (not counting Xfree86 which was base for X.Org Server) to implement most features it has today and still missing some without any good perspective to implement them in near future. It also usually implemented it later than other operating systems. For example threaded input. It started in 2010. Took 6 years to implement and landed in X.org Server 1.19 released in 2016. Years after Windows. Same goes with graphics acceleration. Xgl was released in 2006. Quartz Extreme, which provided GPU acceleration on macOS (Mac OS X) was released with Mac OS X 10.2 Jaguar in 2002. Also things like mixed refresh rate works fine on both Windows and macOS since years and X.org still cant handle it after years of development.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 10, 2020

Screen share

The Jitsi Meet app is broken. Its authors say "there is nothing we can do from the Jitsi Meet side."

screen recording

SimpleScreenRecorder and Vokoscreen are both broken.

Night Light

Redshift is broken. Its author says "Redshift does not support Wayland since it offers no way to adjust the color temperature".

I am not interested in surrogates, since those tend to only work on Gnome and maybe KDE, neither of which I use.

How can you say "X.org just works" when HiDPI support is broken

HiDPI works for me with Qt when you export QT_SCALE_FACTOR=2. I do not need anything else than this.

multi screen is broken

Xrandr does the trick for me, and has been doing it for a decade or so.

mixed refresh rate doesn't exists at all

Not since I touched a computer for the first time did I ever feel an urge to want this.

I get it that Xorg is missing some features. I even get it that a complete rewrite from scratch may be necessary. But I don't agree with the attitude that it is ok to do this in a way that breaks existing applications like the ones I cited as examples above.

@HolyStephano

This comment has been minimized.

Copy link

@HolyStephano HolyStephano commented Nov 10, 2020

But I don't agree with the attitude that it is ok to do this in a way that breaks existing applications like the ones I cited as examples above.

But we do this literally all the time by updating dependencies in general. One library updating and removing a feature can break pieces of software, and this does happen fairly often, either a feature gets deprecated and removed, or updated to require a new argument, or whatever the exact case may be. We already have an ecosystem where that's possible, and literally no one is forcing you to use wayland. You can use Xorg until it dies in its' current form.

Your attitude towards wayland is "It breaks some things for me therefor bad" where I personally don't experience any of the issues you have, but experience lots of issues in general with X. From my perspective, I should be writing a gist bashing X called "Think twice before using Xorg! Wayland fixes everything!" but that's stupid. Why are you taking an approach attacking wayland instead of actually letting people make the decision themselves?

@bernharl

This comment has been minimized.

Copy link

@bernharl bernharl commented Nov 10, 2020

Night Light

Redshift is broken. Its author says "Redshift does not support Wayland since it offers no way to adjust the color temperature".

I am not interested in surrogates, since those tend to only work on Gnome and maybe KDE, neither of which I use.

Gammastep doesnt require Gnome or KDE, I'm using it on Sway no problem.

How can you say "X.org just works" when HiDPI support is broken

HiDPI works for me with Qt when you export QT_SCALE_FACTOR=2. I do not need anything else than this.

Per monitor scaling is impossible on X

multi screen is broken

Xrandr does the trick for me, and has been doing it for a decade or so.

Same here as above, X cannot treat each monitor as a separate entity and therefore several things, liked mixed dpi and mixed refresh rate do not work. Variable refresh rate also doesn't work with multi monitor.

mixed refresh rate doesn't exists at all

Not since I touched a computer for the first time did I ever feel an urge to want this.

Playing games on a 165 Hz monitor while having a 60Hz monitor on the side for browsing, chatting, etc. is a pretty normal use case. Right now that is pretty terrible on X as you have to feed both monitors either 60Hz (ruins the game experience) or 165Hz (awful amounts of screen tearing on the 60Hz monitor, this is what I'm using right now as I have an Nvidia GPU and cannot use Wayland properly yet).

@lestcape

This comment has been minimized.

Copy link

@lestcape lestcape commented Nov 10, 2020

Wayland isn't not a problem of specific developers that have not resources to implement the missing functionalities. Is also a problem for organizations like GNOME, that have the resources to fix big problems. They just don't want to take that in account because Wayland is more about politics in GNOME than it is about a functional decision. In fact several things in GNOME are just technical but not functional decisions. Not all that is good in theory can be implemented in a good way in practice. Some times is just not convenient change all, because is a lot of work and there are not human resources to assimilate that task. It would be much more convenient if they accepted that and did not try to impose incomplete things like Wayland. This next thread shows what I'm talking about:

https://bugzilla.redhat.com/show_bug.cgi?id=1367666

@lestcape

This comment has been minimized.

Copy link

@lestcape lestcape commented Nov 10, 2020

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 10, 2020

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 10, 2020

They should say "want to do" instead of "can do" to be accurate.

I guess they are just using Electron, which is just using Chromium...

@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 10, 2020

What basic features?

  1. To set exact fonts dpi!
    There is no way to set fonts DPI to exactly 100, the same as xrandr --dpi 100x100 on xorg. I can't make clients look the same as on xorg.

  2. Once again X11 bell.

@lucastrvsn

This comment has been minimized.

Copy link

@lucastrvsn lucastrvsn commented Nov 10, 2020

So, apps you use broke and you are pissed with wayland? A different server protocol created to solved all xorg bs? My desktop runs WAY smoother on wayland and I DONT HAVE TEARING, such an advance. Or now I can do some amazing games on my primary monitor 144Hz and DO CHATTING NORMALLY on my another 60Hz???? Or what about my HiDPI laptop??? Just works. Wow!!!! And.... WHY I CANT DISABLE MY COMPISITOR WHILE GAMMING ON XORG???? Ohhh.. now I can on wayland. AMAZING! Maybe you can stuck with xorg and use outdated software so we CAN MOVE FORWARD!!!!!!!!

Linux world need standards, I'm tired of all this mess.

Are we in 1990 again or we are moving forward? My God.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 10, 2020

Linux world need standards, I'm tired of all this mess.

Agree. Standards.

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 10, 2020

@DragonSWDev

Wayland does not provide any high level graphics/text rendering API (e.g. partially Win32/D2D in Windows, Quartz in MacOS) which leads to a situation where:

  • Each toolkit must implement its own font rendering (including antialiasing)
  • Each toolkit must implement its own scaling
  • Each toolkit must implement its own output acceleration (using whichever API it prefers)

Where all these features are provided out of the box by sane operating systems. As a result, applications using different toolkits may look and behave differently under Wayland and there's no common configuration of any sort to unify/standardize that. That's pure insanity and it also leads to a duplication of a ton of work and that also makes development for it super difficult in case you're not using Qt/GTK/any other Wayland compatible toolkit.

Lastly and you say screen sharing is available - how efficient (in terms of CPU use) and fast (latency and bandwidth) it is? I guess it totally sucks while RDP for instance is perfectly usable via a 56Kbit connection. And before you tell me that high speed Internet is not an issue, in many parts of the world it's a dream and people keep using the 2G internet where VNC (which is what Wayland can only offer as it only works with raw pixels) is basically unusable. And what about streaming video via VNC? RDP allows to send compressed video streams and decode them on the client's side. RDP allows to render 3D at the client's side. RDP allows to send compressed audio.

APIs, APIs, APIs for f's sake. Wayland offers practically nothing. OK, X11 is outdated and doesn't support $this, $this and $this. Well, in its current state Wayland offers 50 times less than X11 does though "hacks" and "extensions".

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 10, 2020

Here's a nice description from wlroots ( https://github.com/swaywm/wlroots ):

Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 50,000 lines of code you were going to write anyway.

Think about it: writing a new compositor for Wayland requires writing as a bare minimum 50 thousand lines of code. Now tell me who the hell would want to work with this crap. Neither XFCE, nor IceWM don't even have plans to support Wayland - it's so broken.

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 10, 2020

You cannot blame developers for not wanting to port their applications to Wayland when it requires so much work and given that no one particularly cares about stable APIs in Linux, it's not certain that the code you painfully write will even work several years from now. This is utter crap. This is not how you attract anyone.

@mikhailnov

This comment has been minimized.

Copy link

@mikhailnov mikhailnov commented Nov 11, 2020

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 11, 2020

@birdie-github There really is not that much code duplication. For font rendering, most toolkits use the harfbuzz/freetype stack. For scaling and output acceleration, most toolkits just use opengl. In X there is XRender+glamor that would draw primitives with opengl inside the server but it generally has worse performance locally than having the client call opengl directly. Yes wayland is low level, you won't see it unless you're writing a new toolkit or display server from scratch. You don't need to write 50k lines of code unless you're starting a new display server from scratch. If it's too much then you can pick a toolkit and run with it, things get a lot easier when you do that.

@lestcape

This comment has been minimized.

Copy link

@lestcape lestcape commented Nov 11, 2020

Wayland is. It is too low level.

This isn't the point to me, because a compositor solution will always be a low level solution. To me this is a Wayland issue yes, but can also be see as a problem to create an standard in Linux, because in practice we have a solution. So, is just that we need an standard that can be implement in all Linux Wayland clients (but this will probably never happen).

So, in this context you can see Wayland as the protocol that exposed all the disorganization of our Linux communities. This is because we also can see Wayland not only as the cause, but also as the straw that broke the camel's back.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 11, 2020

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 11, 2020

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 11, 2020

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 11, 2020

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 11, 2020

@ismaell

Let's take IceWM for instance. It doesn't use any toolkits. How are its developers supposed to port it from X11 to Wayland? What about a dozen other lesser DEs and window managers? Are you proposing each one of them should create ... a new UI toolkit just to support Wayland? They don't want to use either Qt, or GTK because those come with a ton of dependencies and have their own limitations, as well as they are not exactly 'lightweight' so to say. I do understand that modern X11 applications also work similarly to Wayland in terms of rendering but still using X11 interfaces is a hundred times easier than programming for Wayland because it's so low-level.

@cyclopsian

I've already shown how graphical applications can be coded for Windows, MacOS, iOS, Android in less than a hundred lines of code because all these OS'es offer a standard graphical toolkit. There's none for Wayland (to be fair there's none for X11 but Wayland was supposed to better, right?)

You say an application developer can use this, this and this - (how) is it all standardized? Will it be here in five years time? Are APIs stable? How easy is it to use freetype + harfbuzz, for instance? For mature OSes you don't have to think about implementation details: it's right there, it's documented, it's guaranteed to work.

XEmbed? No. What about a systray implementation? No, depends on XEmbed.
Weston in 2020 still doesn't have a taskbar for ffs. Sounds like a bad joke.

Weston is the reference implementation of a Wayland compositor, as well as a useful environment in and of itself.

Useful environment they say. The reference half-broken implementation they say.

You do not introduce something new which is meant to replace something old and deprecated while omitting critical features required for working with your graphical environment. Again:

  • Clipboard and middle mouse paste (took forever to be implemented in Wayland - I'm not even sure it works)
  • Systray/XEmbed (still not there)
  • Drag-n-drop
  • Screen sharing/casting/recording, remote desktop'ing
  • Taskbar for God's sake
  • Fine window management (which is why Wine still doesn't support Wayland)

It's now 2020 and KDE still struggles to support Wayland properly: https://community.kde.org/Plasma/Wayland_Showstoppers

A major DE with a financial backing and dedicated programmers. That speaks a lot about how Wayland was designed and it tells me that Wayland is a thin layer on top of KMS. It's not a full-featured graphical protocol/server which is why people are so averse to it.

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 11, 2020

@birdie-github If you really don't like any of the existing toolkits then yes, you'll have to make your own. Providing a toolkit is outside the scope of both X and Wayland. If you wanted to port icewm, my suggestion is to use wlroots and pango + cairo. That will handle freetype/harfbuzz for you.

I can't say for sure what's going to be supported in 5 years. You'll have to ask your distro what their support policy is. Going through your list:

  • Clipboard is included in core wayland, primay selection is an extension.
  • Systray is provided by different APIs. An XEmbed-like API is very unlikely to happen.
  • Drag and drop is included in core wayland, though KDE's implementation is buggy now and needs work.
  • Screencasting is provided by different APIs, most likely using pipewire.
  • Taskbar depends on what the DE wants to do.
  • Fine window management from any old program is very unlikely to happen, though see this patchset for progress on wine.

Wayland is itself not intended to be a full-featured graphical protocol or server. It's only a protocol that can be used to build a more full featured display server. You can make it a thin layer on top of KMS if you want.

@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Nov 12, 2020

This almost feels like comparing OpenGL to Vulkan.

@brneor

This comment has been minimized.

Copy link

@brneor brneor commented Nov 12, 2020

I've read a ton of misinformation today but you sir, you deserve the crown of stupidity.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 13, 2020

For all the Wayland proponents here, why argue in places like this, wouldn't it be a better use of your time to send PRs to fix things like MaartenBaert/ssr#431 and vkohaupt/vokoscreenNG#51. (But please in a way that it works outside of Gnome and KDE, and does not introduce additional dependencies.)

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 13, 2020

@probonopd This is not the right place to ask for that. Please consider putting out bounties for any specific issues you want fixed. A list of sites to do this can be found here: https://github.com/fossjobs/fossjobs/wiki/Resources#bounties

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 13, 2020

Wayland is itself not intended to be a full-featured graphical protocol or server. It's only a protocol that can be used to build a more full featured display server. You can make it a thin layer on top of KMS if you want.

And that's why people cannot accept it. As bad as X11 is, it's still a high-level protocol which can be used relatively easily while giving access to crucial features out of the box that's why we have several dozen window managers and a dozen DEs - and they all work pretty satisfactory. And with Wayland we have Gnome. Great. KDE is still struggling. Other DEs and WMs? So basic they are barely usable - they look more like tech demos while a basic barebones TWM for X11 works better and offers more features than Weston which contains ~20 times more code.

We need a common UI library for Wayland which implements high level stable APIs while not being bound to Gnome libraries and is not Qt. Wake me up when the said library is available, usable and guaranteed to work 20 years from now (Linux X11 applications from 2000 still work in 2020 quite nicely).

Also it would be great if Wayland itself offered some features without having to implement them via a compositor, i.e.

  • Windows retention in case a WM/compositor crashes or you want to replace it on the fly - this one is critical IMO, because in both X11 and Windows you can kill the window manager and your applications will continue running. In Wayland once your WM crashes, all your running applications are dead.
  • Screen sharing/casting/recording
  • Clipboard
  • Drag-n-drop
@snakedye

This comment has been minimized.

Copy link

@snakedye snakedye commented Nov 13, 2020

@birdie-github X11 isn't that much high level than Wayland. The reason why no one uses the low level API for X is because they are for the most part, completely impractical with modern technology. Instead they use 25 hacky extensions to accomplish the same things Wayland does at a lower level and since X is terribly bloated, and has so many extensions potentially depending on those obsolete APIs, you can't touch anything.

It's understandable that no one wants to work with this and you can quickly understand the limit of such a design. If Wayland was as convoluted as X we would eventually fall in the same situation. X is practically dead now but it shortcoming started showing up years ago. It took marginally more time to implement technologies that were readily available on Windows or Mac.

By delegating the heavy work to the compositor, the Wayland protocol can stay very lean, flexible and more future proof.

We need a common UI library for Wayland which implements high level stable APIs while not being bound to Gnome libraries and is not Qt.

There's already wlroots and freedesktop.org. It seems like people here barely take the time to document themselves.

Other DEs and WMs? So basic they are barely usable - they look more like tech demos while a basic barebones TWM for X11 works better and offers more features than Weston which contains ~20 times more code.

No one document themselves before doing rants.

Sway is a more complete, stable and feature rich Wayland compositor than Kwin.

Here's a list of projects using wlroots.

Weston is also such a disingenuous example.

https://github.com/freedesktop/wayland-weston

A small suite of example or demo clients are also provided: though they can be useful in themselves, their main purpose is to be an example or test case for others building compositors or clients.

It's literally means to be a test demo as to how to write a Wayland compositor.

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 13, 2020

@birdie-github Any such UI library would be very similar in design to GTK and Qt, and would require similar levels of investment. (Minimum tens of millions of dollars and minimum 10-20 years of time) If you really do have that money lying around, I would suggest you spend it on something else more important and just use GTK or Qt, because they exist now and they work.

The general consensus seems to be that adding tons of high level features to X11 was a mistake. Keeping Wayland as a low level protocol allows the complexity of high level functionality to be implemented elsewhere, possibly in Wayland extensions if someone desires. Wayland itself can't offer any of those features you're asking for because it's just a protocol. Parts of some of them are included in libraries like wlroots. In particular though, crash recovery of the display server can't be achieved without an external helper program. (This isn't a limitation in Wayland, it happens in X too)

@birdie-github

This comment has been minimized.

Copy link

@birdie-github birdie-github commented Nov 13, 2020

Instead they use 25 hacky extensions to accomplish the same things Wayland does at a lower level and since X is terribly bloated, and has so many extensions potentially depending on those obsolete APIs, you can't touch anything.

I've seen quite a lot of comparisons between applications running under X and Wayland: there's close to zero difference in performance between them. If anything applications running under X were faster up until recently.

By delegating the heavy work to the compositor, the Wayland protocol can stay very lean, flexible and more future proof.

... and useless for people who don't want to run Gnome/KDE.

If Wayland was as convoluted as X we would eventually fall in the same situation. X is practically dead now but it shortcoming started showing up years ago. It took marginally more time to implement technologies that were readily available on Windows or Mac.

Is Android GUI stack convoluted? What about Windows/GDI? MacOS/Quartz? iOS? All providing high-level APIs and running blazingly fast.

Sway is a more complete, stable and feature rich Wayland compositor than Kwin.

You're joking right? Sway is a tile window manager which kinda makes it useless for absolute most people out there. Have you seen KWin's window options? Its abilities to configure window behavior? This https://www.thelinuxrain.com/content/01-articles/23-tutorial-how-to-use-kwin-window-manager-with-xfce/xfcekwin3.png https://www.linuxtopia.org/online_books/linux_desktop_guides/kde_desktop_user_guide/titlebar-menu.png

Any such UI library would be very similar in design to GTK and Qt, and would require similar levels of investment. (Minimum tens of millions of dollars and minimum 10-20 years of time) If you really do have that money lying around, I would suggest you spend it on something else more important and just use GTK or Qt, because they exist now and they work.

I think you overestimate the cost of the said library by an order of magnitude. I'm not asking to create a Qt alternative which would be as expensive as you you estimated, I'm asking to have a library which offers painting/rendering/interaction primitives which can be used by application developers. The X11 protocol was created by a small team of engineers over a comparatively short period of time.

The general consensus seems to be that adding tons of high level features to X11 was a mistake. Keeping Wayland as a low level protocol allows the complexity of high level functionality to be implemented elsewhere, possibly in Wayland extensions if someone desires. Wayland itself can't offer any of those features you're asking for because it's just a protocol. Parts of some of them are included in libraries like wlroots.

Let's just admit that Wayland was created to run Gnome and be done with it and as such it's a spectacular failure. And even Gnome/Wayland became fully functional relatively recently. KDE is looking to become a first-class citizen in Wayland but other than what do we have for normal users (not geeks and developers)? Nothing. I want to be able to run XFCE/IceWM - I cannot. And I'm 100% sure their developers don't refuse to support Wayland for ideological reasons: they don't want to break their asses writing tons of code because Wayland is so "cool" and "light".

In particular though, crash recovery of the display server can't be achieved without an external helper program. (This isn't a limitation in Wayland, it happens in X too)

And your remark about X is squarely false. You can trivially kill a window manager in X and all applications will continue running as if nothing has happened. WM is not a requirement to run X applications.

Wayland on the other hand doesn't exist without a compositor. All by itself it's 100% useless. This is my major gripe about it.

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 13, 2020

@birdie-github Painting/rendering primitives are provided by any external library you want. Cairo and nanovg seem to be popular. Interaction primitives aren't included in the X protocol and it's very hard to have those in a flexible way without bringing in a full high-level toolkit like GTK and Qt.

Wayland wasn't created for any desktop in particular but you're probably right that only GNOME and KDE had the resources to do a full port so far. It would be nice if things didn't need to be ported, but that's unfortunately not the case and nothing can really be done about that. I can offer more advice on how to port XFCE/IceWM if you'd like.

I wasn't talking about the window manager, I was talking about the display server. There is no way to recreate the WM/server split in Wayland without recreating a lot of the complexity and performance issues of X. It's not worth it just for some small amount of crash protection. If you really need that, my advice is to stay on X for the time being.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 13, 2020

Let's just admit that Wayland was created to run Gnome and be done with it and as such it's a spectacular failure. And even Gnome/Wayland became fully functional relatively recently. KDE is looking to become a first-class citizen in Wayland but other than what do we have for normal users (not geeks and developers)? Nothing. I want to be able to run XFCE/IceWM - I cannot.

Wow. Does this mean that Wayland breaks Xfce, too?

only GNOME and KDE had the resources to do a full port so far

That's what I am criticizing: Wayland is incompatible to existing software and then expects everyone else to have the time and resources to play catch-up to whatever they are up to. Truly community-driven (not paid by a large corporation such as IBM/Red Hat) projects are less likely to have this kind of time and resources.

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 13, 2020

AFAIK at this time the wlroots project is community driven and not paid by large corporations.

@probonopd

This comment has been minimized.

Copy link
Owner Author

@probonopd probonopd commented Nov 13, 2020

Maybe, but to be honest I don't even understand which problem it is trying to solve. Will it make existing screen recording and screen sharing applications "just work" with any desktop environment on Wayland?

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 13, 2020

The wlroots project is a library to build compositors. It has optional, reusable components for screen shots and screen recording, that work provided you use their renderer. (Compositors don't have to use their renderer, it's also optional)

If those applications depend on X11 specific APIs like reading from the root window then no, they will probably still need to be ported. Switching to newer wayland/pipewire APIs for screen casting should yield performance and security benefits.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 13, 2020

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 13, 2020

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 13, 2020

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 13, 2020

Oh, answering by email makes github render it wrong. Here's the diagram again:

.----------------.              .---------------.
| Storage Device |<------.<-----| Recording App |
`----------------'       |      `---------------'
.--------------.         |      .----------------.
| Video Player |-------. |   .--| Wayland Client |
`--------------'       | |   |  `----------------'
  |                    | |   | (many)
  v                    v v   v
.-------+------.     .--+------+--.
| Video | DMAC |-----|->| VRAM |  |
| Input `------+     |  `------'  |
| Device       |     | GPU        |
`--------------'     `------------'
@532910

This comment has been minimized.

Copy link

@532910 532910 commented Nov 13, 2020

Github allows message editing.

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 13, 2020

@ismaell XWayland is designed to work in the same way as Xnest/Xephyr/Xquartz/etc in that the implementation only supplies access to windows local to that X server, and the API will not translate it into requests for windows using some other windowing system. Somebody could attempt to add this, but it's probably more trouble and less gain than porting those few applications to use the newer API.

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 13, 2020

@cyclopsian

This comment has been minimized.

Copy link

@cyclopsian cyclopsian commented Nov 14, 2020

I just don't see why anyone would, it's a lot of work for very little gain. You can still run xwayland with a root window too: https://lists.freedesktop.org/archives/wayland-devel/2017-July/034552.html

@clapbr

This comment has been minimized.

Copy link

@clapbr clapbr commented Nov 14, 2020

And.... WHY I CANT DISABLE MY COMPISITOR WHILE GAMMING ON XORG???? Ohhh.. now I can on wayland. AMAZING!

Weird you say that, on most setups I've ever used it's the opposite. It's quite easy to switch the compositor off in X11 but in Wayland it's usually not possible (thinking of Gnome, Plasma and Sway here).

@ismaell

This comment has been minimized.

Copy link

@ismaell ismaell commented Nov 15, 2020

Actually, disabling the compositor only makes sense in X11. It's a complex topic, and probably whatever performance degradation you saw was more of an implementation issue than a design one.

In both cases, the compositor can choose to to give applications a buffer that goes directly to screen, and it should always do so for full-screen applications, it's transparent.

Also, some video hardware can do the compositing itself with some limitations, so in these cases the compositor could chose to give applications access to separate overlays to render directly to screen.

In this area Wayland improves things substantially, it's model is way better, now we can batch updates in a consistent way, thus avoid artifacts (something that happens in X11 even with compositing); and while this could in theory be improved on X11, the issue is that it isn't transparent to legacy applications.

@mdedetrich

This comment has been minimized.

Copy link

@mdedetrich mdedetrich commented Nov 18, 2020

Regarding people arguing to use wlroots as a basis for compositors, this is likely never going to happen unless they address the elephant in the room, i.e. supporting NVidia GPU's.

We can argue about the whole GPL/proprietary topic until the cows come home, but no major DE such as Gnome or KDE are going to use wlroots because doing so would cut off a significant chunk of their user base which is suicide for obvious reasons.

This is honestly the core issue of Wayland, since its just a barebones protocol that doesn't abstract over hardware its causing all of the other DE's to duplicate this code. X11 has a lot of issues but abstracting over hardware (i.e. Linux related KMS/DRM and even drivers) was not one of them, in fact it was a significant advantage.

Honestly Wayland should have been released along with something like wlroots/wayfire that doesn't play politics/ideology and instead had a focus on usability and actually working. This leads to the other issue which is that Wayland development is overly Gnome centrist which causes a lot of problems for extension proposals. Discussion of Wayland protocols and extensions should be driven a community that has stake in the library (i.e. they are all using and contributing to it heavily) rather than the current situation where Gnome is just shooting down proposals because they aren't designed in the "Gnome way".

@ismaell

This comment has been minimized.

Copy link