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!
I’ll save you a read and summarise the ‘article’ so you can do something more productive, like I don’t know, cleaning your floors with a toothpick or something: “my tools and components written specifically for X and its APIs do not work under Wayland, therefore Wayland is garbage and shit”.
Wayland is not X.org. Let me repeat that. Wayland is not X.org. If you need the functionality that X.org delivers, then you shouldn’t be using Wayland. This is like buying a Mac and complaining your Windows applications don’t work.
Sure, but at the same time wayland turning their back on common use cases like screen sharing bodes poorly for wayland independently of whatever people think of X. It’s a legit criticism that these things don’t work.
Yeah, I was going to say if you are telling everyone to switch to Wayland (which Fedora and others are by slusing as default) then you better make sure it supports the work cases of your target audience, which is Linux users.
Exactly. And this is the same story again and again with Linux. Almost 25 years in the ecosystem and it is like Groundhogs day which results into no being able to maintain desktop users since things break again and again.
So yes Wayland is not Xorg. Does this mean it is better for the community ? Personally up to ~10 years ago I was still able to try and fail and try again and again… for even the trivial stuff. But now I don’t have the time and don’t want to do this again, I want something if not stable at least with a clear way forward and this is not the way this situation goes
The same was said about Xorg, ~15 years ago, and yet, I’m running a business using Linux (both servers and desktops).
The same was said about GNOME 2, GNOME 3, KDE 3, KDE 4, PulseAudio, Linux kernel v2.6 and more or less, any other major piece of software we use daily without even taking notice.
Sure, waylands has it warths and all but 5 years from now, it’ll simply work.
gilboa,
That’s a diverse collection and not all were equally received. Some were non-events, but others were very “noticed”, haha. Gnome3 didn’t break anything for me, but alas it turned me off of Gnome Desktop (non-technical preference). Pulse audio was a good example of a badly managed rollout that eventually got fixed but in the meantime left some people with broken setups.
I certainly hope all the features will simply work in 5 years, but in the meantime what about the breakages now?
It’s very hard to recommend linux to average joes when we still have these sorts of breakages. Some amount of issues are to be expected with a new rollout, you deal with the bug reports as best you can. But in this case we can’t pretend these problems weren’t anticipated, they’ve already had several years to fix them and it’s still not done. IMHO it’s worse that they know they’re breaking things and they’re intentionally not taking responsibility.
Deploying wayland as default with missing features is a consequential decision that will either justify our platform’s widespread reputation in amateur circles of being too difficult and not being ready for general usage versus a platform that is serious about taking on user needs and taking steps to ensure things just work.
Yes, but it’s worse than that. The continual breakage (that alienates users) also causes fragmentation as different distros go in different ways; and this causes extra bloat (more layers of libraries, etc to hide the differences) and divides developer efforts; so rather than everyone (developers, distro maintainers, documentation writers, etc) working together to make one OS awesome they’re all working against each other to create (and continue) a “divided we fall” situation.
5 years from now Wayland might work, but if it does they’ll just break something else (networking? file permissions? USB devices? scheduler? who knows) and it’ll be the same old “In theory this shiny new bauble is technically better than the rusty old bauble, so we aren’t going to bother with any kind of migration plan or attempting to achieve consensus between distros, and then we’re going to roll it out before it’s ready while ignoring any/all of the pain that the transition causes users and developers”.
Totally agree. Things like KDE4 were bad rollouts because distros jumped the gun and deployed it after the developers said it wasn’t ready for usage.
Xorg isn’t going anywhere yet. Distros like Fedora or the non LTS Ubuntu releases will try to deploy these things and see how it goes. LTS distros and enterprise level distros won’t deploy this tech until it is ready. But they will test it in their unstable channels to get it ready.
If you’re an enterprise user or an LTS user this really means little to you because you’re not even close to the bleeding edge and it won’t really affect you.
Wayland didn’t turn their back against common use cases. In X, any app can spy on any other application, which makes it easier to make a screen recording application, but absolutely terrible for security. Instead the application must request screen casting rights from the compositor. The feature to use screen casting exists, people just aren’t updating apps to use it. The idea that Wayland doesn’t support screen casting is a myth.
Noremacam,
You are welcome to criticize X windows all day long but that’s a straw man because I’m not defending the X implimentation. I’m criticizing wayland on it’s own merits. If they do it more securely, that’d be fantastic. But IMHO ignoring user input is regressive and it’s something that we, the linux community at large, need to work on.
It isn’t a myth at all. Wayland is not providing support, that’s individual compositors providing support due to the lwayland’s lack of support. Without support from wayland these are going to end up becoming non-standard features. It’s a bad way to implement features because now applications are going to need to be tethered to specific compositors. If we continue down this path, the end result is going to be a plethora of APIs and network effects coercing users into specific compositors that applications are hard coded to use. I sure hope that’s not what wayland are going for, but given their behavior it might well be.
I remember even Windows 95 had a very simple API. Use HWINDOW = 0, and can access the full desktop. Currently it is a bit more complicated (multiple displays and all), however the screen casting is still simple. And if an application does not want that, they can ask the OS to “blank” their window when casting is active (like Netflix / Disney+ tabs).
Linux (GNOME) had a simple widget to share the desktop too. I think it was VNC based, but very easy to setup.
This is such a common use case, especially with remote-working now, there is no reason not to have that in the standard.
Pipewire is the solution to these use cases, as I understand it. It is designed to supercede Pulseaudio and work with Wayland and Flatpak to handle video/audio going forward. So, unless I’m missing something support is being provided for Wayland environments using the obs-xdg-portal extension and Pipewire.
lakerssuperman2,
You’re right. Pipeware deserves a mention since it is fedora’s answer to the problem.
https://pipewire.org/
Pipewire solidifies the dependency on systemd, which is slowly changing the face of unix from a collection of generic interchangeable tools that play well together to a collection of linux centric tethered tools that require each other. I don’t wish to focus on the systemd aspect, but just to point out that not everyone likes tools to be tightly coupled and this moves more in that direction.
I hope that the pipeware flatpak coupling is extremely minimal and optional, because IMHO streaming APIs should not be coupled to the way an application is distributed. I *think* they just mean that they are compatible with flatpak sandbox containers are not that you actually need flatpak for anything.
Pipewire needs to be implemented in every single compositor, which is a lousy way to implement functionality that should work everywhere. But putting this aside, most users aren’t going to care as long as it works. I don’t use fedora and I haven’t seen it working though. Is there anyone here who has it working?
It isn’t really ready yet for ubuntu.
https://askubuntu.com/questions/1274527/what-is-the-right-way-to-install-pipewire-in-ubuntu
I think it’s going to be a long time before applications adopt pipewire, in the meantime maybe they ought to consider adding it to the xwayland shim so that existing applications can use it without breaking.
I sincerely hope the deployment goes better than pulseaudio, which got there eventually but many will remember as being badly managed at launch.
Alfman stack of errors. Pipewire is on freebsd its dependency on systemd is superficial
https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/321
There is freebsd particular code inside master branch and releases of pipewire what makes on on a bsd based OS really simple to operate.
>>Pipewire needs to be implemented in every single compositor,
This is in fact false the first version of xdg-desktop-portal/Pipewire screen capture was libdrm based. There is a reason why xdg-desktop-portal is being implemented inside every single compositor the name of the company for the reason is NVidia the problem is the screwed up eglstreams implementation where you need to be inside the compositor to get the output screen. Please note using DMA BUF to pass from application to compositor since this is a file handle from root/high privilege it is in fact possible to capture this outside Wayland so allowing individual application window capture without any feature in Wayland protocol todo it. Wait DMA BUF not implemented by NVIDIA either.
The bare min xdg-desktop-portal screen capture needs is the following dbus, pipewire and something allowing direct screen capture with privilege like libdrm.
Remember dbus allows running stuff at higher privilege. This is the real need. xdg-desktop-portal is being wanted implemented inside every compositor because Nvidia drivers are broken and feature poor.
Problem here Nvidia for that direct screen capture by third party application with X11 or eglstreams did not/does not currently support. When I say third party I mean capturing screen while not being inside X11 or inside Wayland. Yes this has also result in times like VNC server of the complete desktop being implemented inside X11 instead of being implemented generic. If you want to see the insane number of hoops you have to do to have desktops remote with opengl applications with Linux due to this problem just look up virtualgl some time. This is why I am against putting these features in Wayland as they don’t really own in Wayland and will lead you into stupid hoop jumping long term due to GPU vendors locking their driver implementation to the compositor instead of being generic.
>>I think it’s going to be a long time before applications adopt pipewire, in the meantime maybe they ought to consider adding it to the xwayland shim so that existing applications can use it without breaking.
This would not require a wayland protocol change. You could in theory make a version of xwayland that talked to xdg-desktop-portal to use pipewire to fake the old see the complete desktop. Of course this would mean for a application to screen capture permission would have to be granted.
Heck in theory xwayland could for particular application have a feature of just reach down to service running at root/high privillage to acesss the desktop with libdrm for the open source graphics stacks to provide it. Problem how to-do this with Nvidia broken offering.
Finally Pipewire being backed by Redhat/IBM at least the development is backed by someone so developers are being paid to work on it. There is all the complains to keep X11 on bare metal going. There is zero funding for the developers to work on bare metal x.org X11 server. Like it or not bare metal x.org X11 server is unfunded no amount of complaining so far has changed that. Instead of complaining the question if you want to keep X11 Bare metal around is who is going to pay for it and how is that money going to be collected.
oiaohm,
We’ve already gone over these excuses. Nvidia only deserves blame for their drivers, but we’re talking about the wayland API. It’s 100% their own fault they have no API.
If they had an API and the nvidia implementation was broken/incomplete on it, then you and I and everybody here could join hands and legitimately criticize nvidia until it gets fixed…in the meantime there’s nouveau.
But right now, as it stands, the wayland devs themselves have not been willing to support a direct screen sharing API.
Nvidia deserves a lot of criticism too, but in this case you are using them to deflect blame for the design shortcomings of wayland.
>> But right now, as it stands, the wayland devs themselves have not been willing to support a direct screen sharing API.
Alfman Stop attempting to weasel here. The wayland developers happen to be the same developers who developed libdrm and DMA BUF and GBM. Libdrm+DMA BUF+GRM provide a direct screen sharing API that is netural to X11,Wayland and Terminal. Eglstreams lack this functionality leading to the work around of integrating support into compositors where it does not own .
Basically its about time you stop attempting to let Nvidia off for providing a crap API in eglstreams so causing knock on effects.
Wayland needs to accept their share of responsibility too though. They could create the API for everywhere else and leave it as a null-op on nvidia drivers until it gets added. Had they done that, then 100% of the blame could be cast at nvidia. And not for nothing but nvidia would have taken notice when their customers complain that only their drivers don’t support the wayland screen sharing API. You can blame nvidia as much as you want but as it stands, given the fact that wayland doesn’t even have a screen sharing API, there’s really no reason for nvidia to do anything about it. I wasn’t kidding when I said I’d join you in criticizing nvidia, but wayland’s choice not to develop an API ends up taking heat off of nvidia because nobody but you is going to blame them for wayland’s features.
Are you associated with the project in some way? I am curious if you could provide any documented evidence that wayland support for screen sharing was planned and dropped due to nvidia.
>>Wayland needs to accept their share of responsibility too though. They could create the API for everywhere else and leave it as a null-op on nvidia drivers until it gets added.
No they don’t Alfman you are being a under researched person here. There is a important reason why screen capture inside wayland is the wrong place.
You have never read all the wayland protocol have you. Where does it say in the wayland protocol that the image data inside the buffers wayland compositor has got from the wayland applications is in fact readable to the wayland compositor. The horrible reality by the wayland protocol they don’t have to be readable. So screen capture at the wayland compositor is perfectly valid to get a stack of blank boxes with no contents that were place holders.
https://en.wikipedia.org/wiki/File:Wayland_display_server_protocol.svg
Take a closer look the party that has to be able to read the buffers internal contents is the GPU drivers/Mesa3d in the early design.
Screencapture no matter how you argue with Wayland protocol design has no place in the compositor at all due to the fact its valid for buffers above the privilege of the Wayland compositor to view. Wayland compositor is only by wayland protocol have to be given meta data about the buffers not the buffer contents. GPU has the buffer contents under the wayland design.
Fun point libwayland-server is not in fact designed to give you access to those buffers either. Weston screen captures by using libdrm and other bits directly. This is not wayland protocol at all.
Why do Wayland developers have to take responsibility for something that not their department at all.
https://wayland.freedesktop.org/architecture.html
Unfortunately the Wayland platform does not specify an API for screen sharing, therefor EGL stacks never implemented it. The MESA drivers already have wayland specific code in them and would have included screen sharing if only wayland had specified an API for it. So naturally we’ve ended up with no API nor implementation. And this is why we’re now forced to implement screen replication functionality in each individual compositor instead. If one of us could go back in time, we could tell them the lack of screen sharing would prove to be a show stopper, but then I don’t even know if any of them would have listened.
>>Unfortunately the Wayland platform does not specify an API for screen sharing, therefor EGL stacks never implemented it. The MESA drivers already have wayland specific code in them and would have included screen sharing if only wayland had specified an API for it.
Nothing like being wrong. You don’t in fact need a different API/ABI to the mesa one to screen capture under Wayland as application. Just you need enough privilege to get the DMA BUF of the output. Basically why are you asking Wayland to duplicate the wheel here.
Lets say you are building generically. Think about it pkexec by dbus you can run a command line tool at higher privilege to get DMA BUF of the output screen or the application you are interested in.
Really this is where you are being stupid Alfman. Simple question why does there need to be a API difference between screen capture and when you are rendering on one GPU and Displaying on another? That is what you are really asking for asking for wayland protocol to implement screen capture is in fact duplicate existing API/ABI.
Like you want the in video card encoder to encode output to video file you want the meta data to give it that is in DMA BUF not the image buffer X11 server gives you so you have the least number of copies possible..
Here is a few totally annoying points DMA BUF Nvidia has to implement for prime support. So Nvidia only implemented it as a kernel mode feature. Nvidia has not being providing DMA BUF to user space. Nvidia binary driver will be getting DMA BUF because without DMA BUF you have other problems.
Think DMA BUF between GPU in prime setup has to cope with one of those GPU being totally reset. This is the same feature you need so a wayland compositor can reset without killing all its applications. Now Nvidia drivers not providing DMA BUF support into userspace…. hello problems.
So screen capture not working is not Wayland protocol problem. Like it or not is a broken driver problem of not providing something like DMA BUF in userspace and means to execute something at the right privilege.
eglstreams in it current form from Nvidia does not support using Nvidia on card video encoder either even as the compostor.
Zero copy screen capture has been implemented for over a decade now in the open source drivers using DMA BUF. X11 screen capture is not zero copy. This zero copy screen capture does not care what is putting the output on screen and does not have to deal with any other code than what mesa3d provides if running at right privilege. Yes if Nvidia had been providing DMA BUF support in their user space interfaces you would have been able to-do the same things.
Really the sooner nvidia binary driver gets out with DMA BUF support proper sooner people may wake up its a generic interface to screen capture.
People keep missing this basic. What is difference between Nvidia/AMD gpu outputting on intel graphics and screen capture for what need to-do the result is there is no major difference other than you need to perform screen capture from user-space this is why DMA BUF is totally suitable for screen capture. DMA BUF is a generic thing that does not need to care if you are X11, Wayland or Text based if it cared items like PRIME would not work right Alfman.
oiaohm,
Sorry oiaohm but your opinion does not make me wrong, it never has. Not too long ago you were arguing there wayland had no deficiencies compared to X and yet when we talk about these deficiencies you pull a 180 and try to make excuses for not having support. Your reasons aren’t even important because regardless of your own justification over wayland not taking responsibiltiy the result is the same: it legitimizes the view that wayland is less capable than X windows because it factually is. It just sucks for users that xwayland is functionally incomplete and screen sharing isn’t a core wayland feature. Oh well, what’s done is done, but like I said wayland definitely could have handled this better.
Frankly if you’re just going to fall back to ad hominem attacks, I’m not reading the rest of your post. I find it unfortunate that this sort of abuse is prevalent in some linux circles since it’s not professional and it hurts the linux community.
Nothing like being wrong.
> It just sucks for users that xwayland is functionally incomplete and screen sharing isn’t a core wayland feature.
This point is completely wrong and being stupid. You are drawing a idea without understanding the facts. Feature not being part of Xwayland does not have to be related to that feature not being part of Wayland protocol.
Wayland protocol is design for between application and compositor this is important.
What does a compositor need to-do. Provide input to the current active window yes. Give instructions to gpu where to put buffers on screen yes. Does compositor need to be taking picture of screen and seeing the final output going to screen the answer is NO. The DMA BUF wayland compositor has for output may only be write able not readable so there is no point passing that to application for attempting screen capture right because its not readable. This is all about privileges. Just like a wayland compositor might only know the buffer size from the application and not be able to read the contents of that buffer as well remember the GPU need to be able to read the contents of the buffer the compositor does not need to.
Wayland compositor is not required to be running with the privileges to perform a screen capture. Remember Wayland protocol was designed for security. Screen capture makes no sense for the core wayland protocol because the compositor does not need to-do it.
Now the fact the wayland compositor compositor not running with the privileges to perform a screen capture does not mean other applications like xwayland could not be.
If there is a bug in Wayland protocol is not the lack of ability to screen capture as you keep on pushing. The Wayland protocol does not define mandatory buffer management solution. GBM/DMA BUF is what the open source drivers use here and works quite well.
DMA Buffer Sharing and PRIME would be worth you look up. Notice when you do that this uses DMA BUF on Linux to take the output of one GPU and share it with another. That DMA BUF describing the output of you GPU can in fact be used in user space with the open source drivers to extract the output of a screen in other words screen shot generic way on open source drivers that does not care if you are running wayland X11 or anything else all it cares is you are outputting graphically. What happens if you perform the commands to screen capture using DMA BUF of the screen on a Nvidia binary driver the answer on the current versions is kernel panic.
This is important Nvidia drivers being broken DMA BUF usage to capture screen means you cannot really put that in Xwayland because feature missing is better than people losing work to kernel panic.
eglstreams Nvidia attempt at there own buffer management has had a long list of insane issues. Yes it don’t support screen capture well at all it does not support compositor restarting …
Have you looked under the hood at all. The answer is NO I know because if you had you would not be saying what saying. So you are spreading incorrect information. Lot of parties on this topic have been spreading incorrect information.
We are in the location because Nvidia has not got their binary drivers out with generic buffer management of some form that is truly useful. This results in people wanting features in Wayland protocol that simply don’t own in the protocol.
I would have no problems if you were complaining that Xwayland had not implemented screen capture and that Nvidia need to get their act in order so it could be. Screen capture problem to fix it does not require altering the wayland protocol.
Its stupid to think this needs a wayland protocol fix. Its you being totally uninformed and overlooking key point of wayland protocol design is security. Screen capture has no place in Wayland protocol at all this is why proposeals to add screen capture API to Wayland protocol have been rejected. Yes the wayland mailing list when these proposals were rejected stated all the same things I just have.
We need a proper effective and functional generic gpu buffer pass around solution on Linux. With that you will be able to generically perform screen captures without care if X11, Wayland or TTY is in use and get screen capture.
Basically you are blaming a problem on Wayland protocol that is not Wayland protocol. The problem is on the underside the hardware interfaces being given to Wayland compositors that application with right privileges should also be able to use directly.
Please note these problems is also why it not common for X11 applications to be using zero copy screen capture. Interesting point rare handful of X11 applications using zero copy screen capture in fact capture the screen perfectly running under Xwayland on wayland. Why this zero copy screen capture is go down to libdrm and go straight around the X11 server completely of course going straight around wayland compositor as well is no issue either.
Yes you had not tested every single screen capture application for X11 with amd/intel graphics to find the rare ones that worked either that tell you a completely different story.
Alfman DMA BUF is a file handle with file permissions this is a big thing. Can you pass a file handle between applications and the file be not read able by some of those applications the answer is yes. Wayland is not X11. X11 the buffers were not designed for permissions around them. Once you have permission system around buffers where you can perform particular tasks is highly limited.
Wayland compositor is not a X11 server replacement should not be though of as that it a X11 server replacement if you do it results in asking for stupid things that don’t fit. Wayland compositor is a compositor there are things a compositor should not be expected to-do. Screen capture is one things a Wayland compositor cannot do.
The DMA BUF file handle of the screen the Wayland compositor has does not have to have the functionality to screen capture. So application wanting to screen capture need to get the output buffer of screen without using Wayland compositor or Wayland protocol and that is the correct way. Problem here is how broken Nvidia ABI/API for doing this has been.
Please note Nvidia has a reason to keep this functionality broken. If generic screen capture on Nvidia comes simple this could under mine their grid hypervisor product. Welcome to tooth and nail battle of the past 10 years with Nvidia.
Nothing like being wrong.
“” It just sucks for users that xwayland is functionally incomplete and screen sharing isn’t a core wayland feature.
This is being complete wrong. Is is in fact possible to implement proper screen sharing in the Wayland compositor that will work going forwards. The answer is NO.
You have incorrect joined that something is not a core feature of Wayland for why its not a feature in Xwayland.
Alfman have you overlooked that a DMA BUF is a file handle with file permissions. This is important because Wayland protocol is designed for security.
Lets say the compositor as a write out DMA BUF of the screen. Yes this is valid with DMA BUF if the Wayland compositor gives that to application because it asked to capture the screen the result is application still captures nothing because the application does not have the privilege to capture the screen.
Next thing Wayland protocol is between the application and the compositor with the application able to use buffers directly controlled by the GPU. Wayland protocol is not in fact designed to connect application to screen. Wayland compositors use like libdrm for the direct to GPU stuff. You want screen output you need privilege that the GPU gives you a read able buffer.
Screen capture like it or not should be a libdrm or eglstreams problem depending on your GPU. Of course we would prefer if Nvidia just provided a libdrm interface to make developers time simple.
By the way your statement that X11 programs with screen capture break under Xwayland is also not 100 percent true. X11 programs using zero copy screen capture work under Xwayland due this being detect you have AMD/Intel graphics and use libdrm to bipass X11 server completely of course this goes straight around Wayland compositor as well.
Think about it why cannot xwayland have different privillage access to the GPU output buffer than wayland compositor. That right Xwayland could have had a direct screen capture right by running a bit as root to get that right.
Alfman,
This is all too common nowadays:
* The Xbox pushes a new Windows/Android app, but that no longer supports even half of the features of the old one
* “Let’s have ReFS with modern features” says Windows. Ah, but sorry you still need NTFS to boot, and yes we are removing ReFS support from non-enterprise versions
* Let’s remove camera App picker from Android, and only use the default one. Oops, there is no way to change the default either
There are so many instances of companies pushing the shiny new thing (probably since “new coke” or even earlier), without actually making sure that new thing can handle the requirements of the older one, it is disheartening.
sukru,
You are right. The idealist in me wants the community to work together to make the platform better for everyone. However kurkosdr recently put it this way “They have commit privs and you don’t”. This single fact speaks a lot to why things are the way they are in many of these instances.
Having commit privs means they can make a change that people don’t want, but that doesn’t result in a large number of users. Really I think Thom nailed it – Wayland is not X.org and doesn’t run X.org applications; it’s trying to create a whole new application ecosystem. There’s a really big graveyard of projects which tried that before.
I’m writing this from X.org and am skeptical about moving to Wayland any time soon. For that I’d really like to know that my Steam library still works, which are a pile of closed source binaries that may not have been updated in a decade, and I don’t get to easily shim them to be launched in some alternate way. Realistically, I’m going to have a better experience on X.org, no matter how many commits happen to Wayland.
Things rarely work for everyone, because in technology there are choices to be made.
RedHat and Canonical want a product that is well-integrated and can be developed at minimal cost while still having the features their clients want. The community wants a set of components that can be mixed and matched like LEGO bricks (so they can build ultra-light or ultra-fancy distros) even if it comes at the cost of tight integration, and they may also want features that may not be of interest to RefHat’s and Canonical’s clients.
Naturally, RedHat and Canonical don’t want to compromise on their vision, because something like that would increase development time and cut into their profits, as well as make their product less tightly integrated. Systemd was the first component to be developed in accordance with this way of thinking (its only dependency is glibc), hence the hate it gets from the community.
It’s worth mentioning that the GNU/Linux stack and GNOME are now worth billions of dollars in value, so of course various companies would try to take creative control of them (which is the next best thing after copyright control). The community should have seen that from a mile away and be careful to whom they grant commit privs.
I predict™ that the community will be more and more disappointed by mainstream distros (RHEL, Ubuntu, Mint) and community distros like Devuan and Slackware will further diverge from the mainstream distros. udev/eudev is an early example.
In general, there is a growing trend among corporations to take creative control of various open-source projects so they can steer the technical direction to their needs, after seeing how Google successfully monetized Android (by keeping the base OS free but adding proprietary Google-specific things on top). And “anyone who doesn’t like it can always fork”.
Even Samsung jumped into the party by taking creative control of EFL, which led to the hilarious “company love control” slide:
https://www.slideshare.net/EnlightenmentProject/edevday-2014816 (slide 4)
It’s not that EFL is world-class code (it’s not: https://what.thedailywtf.com/topic/15001/enlightened), it’s just that Samsung likes the fact they have full creative control over it and can make it work for their needs (SmartTVs, Smart Fridges, internet-enabled toilet plungers etc)
@kurkosdr
Yeah, that’s always been the dark side of FOSS. Especially with copyleft licenses like the GPL. Whoever contributes the most controls the direction of the project.
Lately, corps have been using FOSS as a hook. They put out a FOSS application, let it get adopted, and then start monetizing it.
Except most people want to run applications, and the mainstream distros get all the applications.
Nope, it’s a problem with the repository model in general. A corporation like RedHat or Samsung can simply hire all the people having commit privs on a certain project for an above market-rate paycheck (but far less than the worth of the code) and control the creative direction of the project. The BSDs were just lucky that back then corporations weren’t that interested, and as a result projects like FreeBSD ended up being controlled by universities instead.
There is no easy solution to this. You can have steering committees and such, but then there is the issue of who controls those steering committees.
I know is it a very generalist perspective, but when part of the motivation for a project is change are we foolish to expect compatibility?
A lot of commentary about the lack of Wayland / X.org compatibility seems to frame the debate in shock and horror. Without being an expert in Wayland it appears to me that right from the start it was never going to be turnkey compatible as the project was born out of criticisms of X.org.
Both the “Change to Wayland” and the “Stay on X.org” arguments have very specific use cases, I can’t ever see a reconciliation!
Unfortunately, people have rewarded sensationalism and clickbait articles over rational and reasoned articles.
There is XWayland which will run X on Wayland, and that’s worked well.
I’ve been on Wayland and Gnome3 for a while (Fedora), and aside from a few oddities it’s been fine. Firefox has some small bugs, and I did run into an issue with screen sharing and recording with OBS and Zoom. For, OBS I switched back to X for a little bit, and screen sharing was hit or miss on Linux with X anyway.
Flatland_Spider,
I agree, the xwayland compatibility layer has had a lot of time to mature and is excellent all things considered. You can turn on wayland and X window applications continue to work via the xwayland shim. It is so transparent that it can be hard to tell if an application is using x or wayland. Of course most are still using X.
The things that don’t work generally don’t work because wayland won’t support them even natively, and not due to faults in the xwayland shim itself. Insofar as using xwayland to migrate applications from one technology to another, IMHO this aspect of the transition has been a success.
People reading my posts probably get the impression I’m against wayland, but that’s not really the case… I’m against the bureaucracy and them telling users which features are important rather than the other way around.
At one time, X application would start with a ~20px black border around them and cut and paste between Wayland apps and X apps didn’t work. 🙂 I think the black border is still a thing, but cut and paste has been fixed.
I haven’t seen the black border since Firefox and Thunderbird went Wayland native, which were the last X applications I regularly used. I’ve bought into Gnome3 pretty heavily, mainly out of laziness.
I rage against all sorts of things. 🙂
Of course, I also temper my complaints by acknowledging I’m in no position to make demands or release pole metric screeds like the author of this gist.
Sometimes we just have to shoot an azimuth and see whats on the other side of the horizon, and that’s one of the exciting things about FOSS. Experimenting and finding things people didn’t know they needed.
I feel for the Wayland devs though. Covering all of the use cases covered by X is a big task. X has been around for 36 years according to Wikipedia, and it’s hard to replace something with that much momentum.
They are kind of doing that though. Release with basic functionality and see what’s important. Get it into the hands of people, and let them build on top of it. I am honestly amazed at how quickly it’s been able to mature. It’s 12 years old. Comparatively, BTRFS is 11 and still a mess. XD
Yes, but on the other hand these issues were identified a long time ago and it’s been 3 years since ubuntu themselves specifically pulled wayland over the exact same problems.
https://ubuntu.com/blog/bionic-beaver-18-04-lts-to-use-xorg-by-default
.
We know that wayland devs are not interested in providing an standard API for the features, which leaves it up to the compositor of each linux desktop to render a solution (did you like the pun?). The problem though is that it’s still not working right in ubuntu. Unless they pull a rabbit out of their hat, these features are just going to be broken when ubuntu 21.04 ships.
So instead of addressing the needs of the community, they’ve simply lowered the bar. This doesn’t sit well with me.
@Alfman
I wouldn’t use Ubuntu as a measuring stick. Their engineering isn’t great, and they like building solutions which lock people to their ecosystem.
Ubuntu and display servers is the plague contaminated gift which keeps on infecting.
Screen sharing was pretty flaky under Xorg, and they have a lot more confidence in it then I do. One of the reasons I have Macs.
XRDP and VNC working under Xorg is technically true. However, they are both kind of crappy, and they are both half baked. SSH is tier one remote access solution, Mosh is tier two, and XRDP and VNC are a distant tier three.
Windows RDP is a really good solution, and neither XRDP or VNC really come close to it. One of the best RDP workflows is moving from a local session to a remote session and vice versa. That doesn’t really happen with either XRDP or VNC with Linux.
Let’s go ahead an throw in X’s network features since that was the original remote desktop tech. It works great on a LAN, but it really falls down on remote networks.
There’s also SPICE which is interesting, but it’s pretty niche and limited to VM consoles.
NoMachine was the best remote desktop solution for Linux. It still has limitations though.
Screen and tmux are much more versatile and well tested. Tmux will adjust to the screen size of the terminals which isn’t something which can be said of XRDP or VNC.
I would love if one of these would mature or get replaced by something which really works well. I’m already running my work on a server or desktop anyway due to modern laptops being thermal constrained, and a VDI system based on a modern X network feature would be nice.
All I’d like to do is be able to switch from local to remote (desktop) session and back again for any number of accounts regardless of how the connection was started.
Read as: We don’t have engineering resources and ride on Red Hat’s coattails. So hurry up Red Hat!
Seriously, RHEL8/CentOS8 and Fedora are shipping Wayland by default.
They fully admit this is a Gnome problem, which is mainly supported by Red Hat and not Canonical.
I have had Gnome crash on me, but I can’t remember when the last time was. It’s been super boring lately.
😀
I don’t know enough about graphics to make a determination about any of this. It works for me. 🙂
(I can take offense to the amount of spin Canonical puts into their press releases.)
Flatland_Spider,
That does not reflect my own experience, it just works here. Screen sharing/remote desktop and all. I use it regularly and so do my wife and kids on zoom. I don’t know if this has changed, but even zoom themselves were telling users to switch to X because X worked whereas wayland did not, unfortunately.
https://superuser.com/questions/1221333/screensharing-under-wayland
I think spice is a good substitute for VNC, but VNC is more widely supported. I’m not sure if there’s a Spice alternative to “NoVNC”, which I use to access remote consoles via web.
As someone who prefers the debian flavors of linux, I don’t feel that’s completely fair. Pipewire is created by redhat and for better or worse the development is happening there first.
It reveals a lot about our own OS biases that you’d take offense to Canonical spin whereas I’d take offense to CentOS stream spin, haha 🙂
X was designed from the ground up as a remote display protocol, but the reality is that it was never very good for anything but simple X primitives and standard fonts, even with LBX and such. It is bloated and slow.
VNC is a really simplistic solution that does framebuffer snapshots and sends slow bitmapped graphics. It can pretty much only be sped up by boosting polling frequency (massively increasing bandwidth reqs), or lowering bit depth or putting on lossy compression (usually JPEG). It is the bare bones lowest common denominator of remote display solutions.
RDP is a great solution, but XRDP on Linux is not. It is really just VNC over RDP ports, with all the problems of VNC.
NX (now NoMachine) WAS a good general solution until version 3 when it was taken proprietary. 3 still works but doesn’t support modern desktops with accelerated graphics, alpha blending, compositing etc all. The version 3 derivatives X2Go and FreeNX etc have the same problem. NoMachine versions 4+ have great features but are commercial only (and I hate the interface).
What does work well as a remote desktop solution for Linux these days? Google Chrome Remote Desktop, that’s what. CRD uses streaming codecs (right now, VP9) instead of bitmap snapshots, which means great graphics, variable bandwidth use and way, way better support for remotely displaying moving images (moving windows, videos, games or whatever). It also supports Mac and Windows hosts, and clients are on everything (also IOS, Android, Chromebooks, whatever). It sits on top of WebRTC so it is designed to work around firewalls, even on both sides. It can host both Linux virtual sessions or duplicate what’s on your monitor output (with a small change to startup script). BUT, your experience with CRD might not be so good if you’re not running a Debian derivative (Ubuntu, Mint, w/e) and Wayland is NOT working yet.
Why is some random rant posted on GitHub of all places worth publicizing on OSNews? It’s basically a list of links, that’s all.
But of course Wayland is “broken” at the moment. Not all the whistles and bells have been designed yet let alone implemented. In itself it’s acceptable. Every new feature takes its time.
My problem for a long time has been the lack of a standard implementation and non-efforts at creating one. Of course e.g. GTK and Qt have had their own wrappers for Xorg stuff, too, but they were only wrappers. This time you have to write the internal implementation yourself, too.
Canonical had the better idea of implementing a new platform instead of mere abstractions. On paper Unity sounds like a good standard platform for Wayland (now that it’s been ported to Wayland). It’s a bit of a shame that Canonical screwed up and didn’t from the get-go sign in for Wayland and help push it together with Unity.
Reading all this and wayland architecture document a question has poped up in my mind? Why the hell do we need many compositor implementations? Isn’t it a basic piece of software that is there to perform well defined function? Couldn’t one implementation be standardized upon? It was successful for the message bus, hell for XF86 have been a standard display server and nobody tried to reinvent it, shouldn’t wayland compositor be viewed as a replacement for X server?
If so why can’t that be standardized?
Because Wayland compositor is also your window manager and desktop. With that, the authors invariably find it is convenient to also include your usual panel/docks/global menus/start menu/panel widgets/lock and log out windows/… as well. Otherwise they would have to define APIs for talking to these apps (these APIs are deliberately left out from the Wayland spec as too high level). The result is that the whole desktop environment ends up being a single application, a bit like Gnome Shell is now, or any APIs that may decouple components of the DE are non-standard and designed only for the internal use in that DE.
Technically, there is also libwayland-server, which could be used for porting DEs to Wayland, but its API looks very minimalistic, so all the above DE functions would have to be implemented from scratch anyway. Also, because it is a library, it suffers from the usual incompatibilities between DEs (mainloop, memory management, low level APIs). In practice, it is easier to implement the whole thing from scratch.
ndrw,
Agreed. I think it’s a good decision to let each window manager/desktop have it’s own compositor. It gives them practically infinite flexibility without requiring a highly coupled API, which is something that X windows is criticized for (and understandably so). In effect, letting desktops have their own compositors is a good way to simplify implementation without imposing restraints.
I think wayland’s architectural design is quite good actually. It’s just such a shame they are being so dogmatic and regressive on what features to allow. Most agree it doesn’t make sense for screen sharing to be a function of a specific desktop/window manager, but given the blanket refusal of wayland devs to implement a common low level screen sharing standard, the only place left to implement it is in the desktop compositors.
https://xkcd.com/927/
I don’t get it either. The only “obstacle” to writing a policy-free compositor (which leaves window management up to a reparenting window manager analogous to those under X11) that I can think of is that it makes it harder to implement stupid pointless bling effects like distorting/wobbling windows. Actually useful effects like live dragging, live previews of minimized/hidden windows, and modes that show all windows at once by scaling them should still be easy enough under a policy-free compositor as long as it provides an API for the window manager to control translation, rotation, and scale of windows in real time. That’s what I plan to do for the window system under the OS that I’m writing (I may also have a separate display multiplexing server underneath the compositor, but I’m not quite sure on that).
Wayland has design issues on its own terms. Whether it is X or anything else is irrelevant so making this an argument is weak philosophy. Yes there are kernel and IHV driver issues too which apply to Wayland and X and Linux in general none of which are helping. Honestly can’t be bothered anymore as it should only have to be said once.
Oh come on, Wayland has always been pushed as a replacement for X. And it’s not. And it will never be of any use to users while it continues to be developed as an exercise in intellectual masturbation by developers who are determined to give us what they think is best for us, rather than listen to what we need.
Full comments after reading the gist.
Gnome is the DE the major Linux vendors has standardized on. It’s been this way for over a decade, and consequently, it gets the most love. Why? Money. RH, Suse, Canonicial have it, and they pick what to focus on because time and personnel aren’t infinite.
The devs of the author’s pet DE haven’t gotten around to updating their code. No judgements, but many hands make light work.
Here is the ax. The author doesn’t like RH or Gnome.
OBS is the only one I care about, and it’s works with Gnome. Interestingly, OBS has the largest community.
Maybe this whole thing comes down to a people power problem, and the applications with larger communities or sponsored by companies are in a better position to make the necessary changes? Hmmm…..
From one of the linked Jitsi tickets.
I want to say I’ve used Jitsi screensharing personally, but it was uneventful so I don’t remember. I know I’ve used Jitsi in the past year.
Zoom screen sharing didn’t work that well with Xorg and Gnome. There is one of the reasons I have a Mac. 🙂
As for the Gnome stuff, I don’t know what to say. It’s been like that for well over two decades. Gnome or KDE is supported and everything else is left as an exercise for the end user. Especially for commercial software, which Zoom is.
Who else remembers all of the third-party clients for proprietary software which would break whenever the protocol changed? Good times, good times.
GUI automation software. I haven’t needed this since Windows XP, so I’m not sure how big of a problem this is.
Gnome has broken lots of extensions over the years. The devs make no guarantees about plugin compatibility, so why pick just one when you can have a several dozen bushels?
I think I tried this one, and it wasn’t that useful since I hide the top panel. Also, Gnome is moving away from putting menus in the top panel, or more accurately, programs never bothered to use them to begin with.
KDE support for Wayland is evolving. This is known. Once again, people and money are the problem.
The general consensus on AppImages is they break all the time. One of the reasons for Flatpak is to build something more reliable then AppImage.
Gnome included this functionality in the base system, and it just kicked in. I’m not sure what to say other then, “Ask the Gnome devs what they did?”
Not surprising. Xfce has people power problems, and they’re behind on a lot of things.
I really like Xfce, and I want them to succeed. The reality is, they are behind pretty much constantly, and it’s the same for the DEs that aren’t Gnome because a lack of money and people.
Technically, nothing works properly on Nvidia hardware unless it’s something written by Nvidia.
This is a Nvidia problem. They don’t support Linux outside of the binary driver, and Wayland devs aren’t going to waste time testing against a driver they don’t control. That’s a consistent policy with the Linux kernel too.
Nvidia didn’t even support X that well. X worked because the Nvidia driver replaced large parts of the X stack with their own stuff, and updates would break the Nvidia driver until Nvidia got around to fixing them. Don’t update anything until Nvidia says it’s okay!
Nothing new basically.
Ironically, RH put a bunch of money into supporting Nvidia hardware, and Nvidia fought back to make sure the project got very poor results.
Diversity is survival, monoculture is death.
What’s the “community” equiavlent of “run by a committee”? One of the things about good management is it hides office politics and other nonsense body really needs to know about. Good journalism weeds out the the static.
What an asinine statement, Thom.
Wayland is a replacement for X.org which must at the very least provide the same features, 100% compatibility with older non-wayland applications and add new features, otherwise it’s an f-ing dud.
Microsoft migrated from GDI to Direct2D to compositing however the vast majority of Win32 applications from Windows 95 onward works just fine in Windows 10, including hardcore low-level stuff, which 1) works with global shortcuts 2) captures the screen 3) alters windows decorations 4) uses the systray, etc. etc. etc.
Wayland which requires a ton of features to be implemented in the compositor makes creating such apps impossible because each compositor for Wayland implements them differently, so your screen-grabbing application for the Gnome wayland session, will not work under any other Wayland compositor.
This is f-ing madness.
The pioneering developers who built things like X were solving actual problems and providing solutions. Everything from PulseAudio and on smacks of smug arrogance born out of myopic ignorance.
What’s their big achievements? Oooooh, you built containers? Solaris and FreeBSD had that before you could spell out OpenVZ in fridge magnets. You built a feature anemic display protocol? Ok, it will take a while to even approach any level of parity with X, how long has it been in developm-… 12 YEARS? Are the developers part of the Teamsters Union or something? The only thing that hasn’t become demonstrably worse is init with systemd and I think that’s only because with its perhaps too-early adoption it had the oversight forced upon it from virtually everyone to stay sane.
I used to be excited at the prospect of wider desktop Linux adoption, but now I’m thankful that interacting with that mess is now strictly relegated to a remote, headless SSH session.
So we can conlcude after this discussion that Wayland is a badly managed mess which hasn’t solved the Linux ABI or IHV issues and is forcing a load of unworkable beta code on end users rah rah rah. Okay. Got that.
All of the above is why I’m sticking with Windows because it works and I don’t have to deal with nerdy passive-anger bikeshedding.
HollyB,
While it is disappointing to see friction in the linux community, it’s hypocritical to suggest microsoft doesn’t do the same thing. There’s plenty of “we know what’s best for you and we’re going to force you to take it” in windows. A huge benefit of linux over windows is that it’s open source and you have options. In this case for example, users will likely be able to continue using X windows for years to come if they choose. Linux isn’t for everyone, which is fine. You’re entitled to your own opinion, but just keep in mind that most of us on linux today really started out on windows and then left. It’s no secret that Microsoft has been trying to copy more of linux over the years to get back the large swaths of developers they lost with time, but most of us will not be going back.
Can you knock it off? Standards matter and just because I’m not writing a 50 page report nailing every dot and comma doesn’t mean I am unaware of slack standards elsewhere. I’m going with what works for me and for now Linux is not it. And even if I did use Linux by default it’s not as if issues magically disappear. If somebody wants to pay me to write a 50 page report I’ll consider it but until then I have other things to do.
The number of reports I have read that gather dust and nobody acts upon and pretend don’t exist when the next predicatable disaster arrives is a longer list than the reports which are actioned. One of my clients is an auditor and I’ll just say he gave a resigned sigh when the subject came up.
Don’t get me started on sexism and complicity in the workplace. Short version: I’m done with it. Sort your own mess out.
Previous comment stands “as is”.
HollyB,
I haven’t said anything about it yet because I was hoping it would pass, but it has not so I have to call it out: you’ve got a serious chip on your shoulder. You aren’t even trying to be respectable. You’ve been rude and condescending to myself and others just for differences of opinion. It seems to be your go-to response whenever you are challenged. No am not going to “knock it off”. I’ve never seen this level of unprovoked rudeness and hostility on osnews before, sheesh.
Great, I have no problem with your preferences, but you clearly have a problem with other’s.
You can say whatever you want to say. You deserve a voice and I’d hate for anyone to feel they’re being silenced or mistreated. But when you use your voice to disrespect others and tell them to knock it off, you are the one who is trying to silence others. That’s not cool!
You are deluded if you think this thread or topic has anything to do with sexism, it does not. Not for nothing but I’ve stood up for you on multiple occasions (like here http://www.osnews.com/story/132832/nvidia-prepares-xwayland-opengl-vulkan-acceleration-support/#comments ). Are you familiar with “the boy who cried wolf”? The problem when you assert “sexism” when there is none is that people will stop paying attention to it. Sexism is real, but it does a disservice to the women who are experiencing for real when you resort to “sexism” as a mere argumentative tool in disagreements.
That’s fine. I hope that we can have mutually respectable conversations in the future even when we disagree.
Stop jumping the gun and putting words in my mouth and reframing and rewriting everything to suit the argument you want to force. No we’re not friends if you’re doing that. Not even close. Look up the myth of “Little Red Riding Hood” if you’re playing that stupid tit for tat game.
Other than this knock.. it… off. For the second time.
End of.
HollyB,
Trust me, this is not the type of discussion I want to have. We don’t have to be friends, but even among strangers we should aim for respect I think I deserve that much, and so do you.
I don’t really get it.
I understand it’s very hard to be civil when others are not, but even in re-reading this thread I see no reason for you to become aggressive. I won’t stop posting my opinions, but I will stop this meta discussion since I’m not here to criticize people and it’s the last thing I want to do on osnews, but I feel it’s something you needed to hear. Regardless of how this specific thread ends, please do consider how your choice of words set the tone for a civil discussion.
Thanks for chatting.
@Alfman
So you can’t be bothered to look up “Little Red Riding Hood” mythology even on Wiki yet I’m supposed to listen to and put up with every reason and tired excuse for the past 10-20 years which still haven’t been resolved and from comment in here look like they will never be resolved? I’m supposed to put up with a largely male dominated profession and get berated simply for posting my fair and reasonable administrative view of the issue and exercising my personal choice?
As I said my first comment stands as a statement. It wasn’t a discussion and I have washed my hands of the topic. Let me know when you have a product ready for prime time and I’ll consider giving it ten minutes but otherwise not interested. I only use stuff which works. If that triggers shouty men again not my problem.
HollyB,
I have no idea what you are talking about.
This is a largely male dominated profession, however you seem to be bent on taking your issues out on all men, even those of us who have not wronged you. 1) you were not berated by me for posting your view, 2) I’ve stood up for, and 3) you’ve been completely hypocritical in the way you treat others.
These comments actually are for discussion. Go ahead and wash your hands of it, but it doesn’t negate other people’s right to comment, so don’t get upset when we do.
I’ve always maintained that linux isn’t for everyone, including in this very thread. Linux is not for you, but you do not speak for everyone else. At the risk of being redundant “I have no problem with your preferences, but you clearly have a problem with other’s.”
A little off-topic but do paying users get a possibility to filter comments section? ie to block comments from certain users? I would pay for that.
Frankly, all this is solvable by simply choosing your hardware and software wisely, or at least not being totally ignorant about it. Using Windows is giving up all hope – you end up with a crappy, untrustworthy platform forever. I can see why people do it when they have no choice but, from what I read here, you are not forced to use it and you are literate enough to switch to anything you like.
BTW, I’ve been on Xfce for the last 2 decades and will be for at least another one. I’m interested in Wayland in a context of impact on the Linux community and the software ecosystem (I’m mostly concerned about governance and fragmentation) but I don’t need it until it works better than Xorg for me.
ndrw,
+1 for xfce, I really like that it’s a lightweight desktop. Technically I have capable hardware to handle more demanding software. But for usability and aesthetics I often find that I actually like the basics better.
I try to change it up every now and then (usually with hardware cycles). I’m actually on KDE now. I’m not sure what I’ll use next. It’s probably gnome shell’s turn in the rotation, although I wasn’t a big fan of gnome3 last time. I preferred gnome 2 and used mate for a while. I tried unity but it was never my cup of tea. I think my favorites are Xfce and KDE.