Solving Every Wayland Problem In Terrible Ways
Vložit
- čas přidán 11. 07. 2024
- From the creator of "Boycott Wayland" we have a whole new project to address problems in Wayland, many of which have already been addressed but the creator doesn't like the clearly good solution.
==========Support The Channel==========
► Patreon: brodierobertson.xyz/patreon
► Paypal: brodierobertson.xyz/paypal
► Liberapay: brodierobertson.xyz/liberapay
► Amazon USA: brodierobertson.xyz/amazonusa
==========Resources==========
Boycott Wayland: gist.github.com/probonopd/9fe...
Wayland X11 Compat Protocols: github.com/probonopd/wayland-...
Issues: github.com/probonopd/wayland-...
ASPEED AST2500: www.aspeedtech.com/server_ast...
=========Video Platforms==========
🎥 Odysee: brodierobertson.xyz/odysee
🎥 Podcast: techovertea.xyz/youtube
🎮 Gaming: brodierobertson.xyz/gaming
==========Social Media==========
🎤 Discord: brodierobertson.xyz/discord
🎤 Matrix Space: brodierobertson.xyz/matrix
🐦 Twitter: brodierobertson.xyz/twitter
🌐 Mastodon: brodierobertson.xyz/mastodon
🖥️ GitHub: brodierobertson.xyz/github
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
#Wayland #Xorg #Linux #OpenSource #FOSS
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation. - Věda a technologie
I'm pretty confident that we could've avoided this whole Wayland FUD if it was just named Xorg 2
Or X12
@@aeth2kilosdidnt brodie make a video explaining how wayland basically *is* x12?
or if they were not fundamentally different
@@giusdbgit would be more accurate to say that Xorg is more like a wayland compositor, since it is an implementation of the x window system protocol in the same way that a wayland compositor is an implementation of the wayland protocol.
Source: xorg wikipedia article first sentence.
@@linux2420Except it isn’t.
Portal has been ported to the N64 by the way.
It was, but somebody fucked up the portals and caused a loop, so it is now stuck in limbo falling at terminal velocity between the blue and yellow portals!
Blame Aperture labs releasing their toys!
But can it run Wayland?
The basic idea is one I considered, then rejected for one simple reason, you still have to get the compositors to implement your ideas and part of the point of wayland is to have all compositors implement protocols for intercompatibiity.
Meanwhile X11 does this with no problem by just having only one compositor, and the customizable parts are an addon module you can even restart at runtime.
dealing with dbus is such a pain that I completely understand trying to avoid it
that said, given how fully it's been embraced by gnome, etc., it seems like we're stuck with it
@@09f9 No, dbus itself kinda sucks architecturally, compared to Doors, XPC, or even 40-year-old Berkeley Sockets (The Internet is a form of IPC if you think about it hard enough)
Im using void to be hipster and even for end user dbus is a pain
If you're not using DBUS directly you're very likely using another tool that implements the same protocol, often time you'll see people suggest dbus-broker
@@supercellex4D You are comparing apples to oranges, here. Doors and Berkeley sockets are IPC. XPC and DBUS are RPC's. And I can't see any fundamental diference between dbus and XPC architectures. Both are server-clients architecture using they own IPC. XPC has to deal only with apple stuff, between apps so it's simpler. DBUS has a broader field, to send messages about the whole OS, so it is more complex.
That said, I've used DBus with bash scripts, pretty easily. I was surprised how easy it was the first time, you can control the whole DE with a bash script.
The real problem is having too many protocols. Why should every Wayland client also have to be a DBus client AND a PipeWire client just to do Wayland things? That's too much complexity.
They should have defined Wayland as a protocol inside DBus. That would actually reduce the number of moving parts. You can pass FDs through DBus.
xkill doesn't kill applications, by the way. It just snaps the connection between the client and server. Most of the time, that leads the application to terminate, but not always.
There's also that problem
But I relied on that behaviour to not terminate a very specific app! This is a very serious problem! /s
Having hangups around d-bus, portals and pipewire is kinda weird. Much of the complaints with wayland are around all the repeat work that needs to be implemented in each wayland compositor, but having these separate components definitely avoids a lot of that, and a lot of it just makes sense to be separate functionality.
The icons stuff seems like it could be nice. I'm guessing wayland wants to avoid windowsy shenanigans where applications would animate their icons and other things.
Also I think the key-value stuff is a big part of the point of d-bus and it's not just specific to graphical applications.
well maybe that's just a consequence of Wayland's architecture? On X11 the window layout manager is a plugin into the server, as it should be, so you don't have to rewrite the whole server if you want windows to be laid out differently.
it's like ordering a burger but saying you don't want a patty or buns required
Like that SpongeBob episode. You get salad and tea at the Kuddly Krab.
That's not what it is about, you are misunderstanding what probonopd is complaining about. Those dependencies are for the applications themselves that need to be integrated, not the desktop portal. Maybe you should try making applications for wayland and you would see.
you have to build a grill for every burger
@@notuxnobuxwell, slapping the minimal portal code and putting in the necessary dependencies? It's much, much more simpler than what X11 used to have.
@@rawrrrer Not true at all. It's a minimum of 2000 lines of code, multiple dependencies and pipewire is a single implementation with no standard and no protocol documentation owned by IBM. That is done in 5 lines in X11 with no dependencies.
I'm only a few minutes into the video but I have a theory as to why Wayland is so controversial, apart from the fear of new things: Wayland critics think broken apps are Wayland's problem, Wayland thinks broken apps are the app developers' problem, and the app developers aren't in the room.
Xorg has been a stable target for so long that people have forgotten that it's normal for software to change
backwards compatibility is the reason why MS operating system still exists@@BrodieRobertson
Why change it though? I've seen zero benefits from Wayland @@BrodieRobertson
11:54 gamescope heavily uses x11 atoms. They use around 100 custom gamescope specific atoms. So yeah, in the gamescope wayland compositor you have to use x11 atoms to control gamescope. These atoms are used in decky loader plugins for example. Having protocols for all those things is a far messier solution.
Aren't atoms used here for lack of any other/better alternative? In a portals/protocols world, you just define one that makes sense for Gamescope because Gamescope exists to do a particular thing. And maybe because that thing kind of involves X11, maybe atoms are the right way to do that now and into the future?
@@knghtbrd I don't the idea is inherently bad but so need atoms specifically or is there a better way it can be handled
@@knghtbrd
And wait untill GNOME decieds to implement it 10 years later?
I love some of the stuff Wayland has brought to the Linux desktop, but the bikeshedding with designing and implementing Wayland features, especially from Gnome, really frustrates me.
It's less bikeshedding so much as many people having ideas and presenting them and various people presenting various other options and gnome/redhat just having a hard stance on anything that isn't what their business partners care to fund development for... but also not accepting outside development efforts, and broad underfunding in general of the desktop side of things.
I consider it more like engineers fighting each other without a specific goal to accomplish and fighting for what they think it's the best lol
In the meanwhile, I used Wayland for almost a year now without major annoyances. I enjoy my working fractional scaling and even tested today KDE's preliminary HDR support in the Plasma 6 beta.
I use XFCE, so no fcking wayland.
@@Henry-sv3wv I do look forward to the day xfce gets wayland support... but i kinda doubt it'll ever be particularly extensive support. KDE is what i'd like to use, and i should try it again at some point since it's been a bit over a year since i last tried it. It was still a kinda death by 1000 cuts situation though, but I know various things have been fixed and a lot of stability work has been done. The worst of my issues which i'm not sure on the status of were graphical glitching and weirdness around fonts with the native applications. Also just kinda big memory footprint, some components seem to even need mysql... although i've heard that has also been fixed.
I don’t use Linux desktop I just come here for all the drama, this is best than any soap opera 🍿
You can't truly appreciate the drama until you've distro hopped like a 1970's disco swinger
I have discovered that PyGame can set its window icon correctly without a .desktop file on Wayland, so I've made an issue report on the compat-protocols repo (issue ID 5). But Firefox Developer Edition somehow can't, so it gets the white W on a yellow circular background.
It largely depends on what the compositor implements and if the software is capable of using it
To make a year "The Year of Linux on the Desktop", we could just use the drama as advertisement. "Are you still watching Netflix, or did you already get yourself involved in discussions about Systemd, Wayland, ..."🚀
i have a suggestion: please, enable dark reader on pages that are very light by themselves, because when you switch to them, it's a bit of a flashbang :D
Turn on lights, watching videos in the dark isbad for your eyes
dark reader is a godsend, i really love it
"Good luck getting rid of D-Bus and pipewire and portals". Look, I don't have any of these on my Unix systems (Linux or otherwise) and I never will. While I cannot comment on pipewire or portals, I can assure you that I will never run the D-Bus code on my machine. Have you seen how bad it is? It's like if a first year student got hired as an intern and wrote the code.
You're probably running a distro like gentoo, or void I would assume, it's not that you can't do it but it's like being worried about a bash dependency, it's such a standard feature that it's not really a concern
ps aux | grep dbus
you're running it
Note that wlroots and xdg-desktop-portal-wlr does not support almost everything that people expect on desktops. This is because wlroots' author dislikes D-Bus and the portal infrastructure too. The only reason more protocols aren't implemented in wlroots is that there are no contributions to ext- namespace for these things in wayland-protocols that wlroots would be willing to implement. That's where Simon Peter (probonopd) should focus his efforts.
I've noticed that given enough time he comes around to things that he initially absolutely hated, tearing control being my favourite example, early on Simon was vehemently against it but it seemed as it gained more interest he changed his tune. At the end of the day it's super easy to make a new protocol, it's just an XML file but those implementations are where the real change can be made.
Wait, you mean in order to run Linux now, I need to have the Linux kernel? ;)
Bloatware!!!1!!!!11!!!1!
ngmi running a bloated system like that
but wayland runs on systemd that aren't linux
I love the names of the folders in the repo. Gives me Subversion vibes. Does he happen to have a gist about why git is bad, and really we should use Subversion or CVS by any chance? :p
Hahahaha... I would love to see that.
Actually "GNOME breaks some feature" kind of equals "Wayland breaks some feature" because Wayland kind of forced every environment to have its own graphics server and it's very unlikely that everyone will support everything equally good. I think this fragmentation is really a major issue of Wayland.
it's not a major issue, every compositor doing its own thing is intentional design
@@idk-sy3iu that's fine for the automotive industry and steam deck, but not for the linux desktop. Desktop applications dont want to write duplicate code. Also sometimes each compositor ends up writing similar protocols but with minor differences. If wayland was governed better then this could have been improved. But yes, wayland is intentionally bad on the desktop because wayland is designed that way, I agree.
@@notuxnobux there's no such need for duplicate code because the protocols are universal
@@idk-sy3iua protocol needs an implementation, the implementations are all different
@@idk-sy3iu no they aren't because each wayland compositor implements its own extra protocols. Those extra protocols are required to make a proper desktop.
I actually can agree with some of these ideas. Wayland is being actively pushed in production, while some basic stuff isn't even decided yet. Stuff like window icons and window position control should be in basic protocol parts with maximum priority. This is what defines how apps are made and what abilities developers have in terms of window control.
Also, api for getting windows info or killing apps definitely should be a part of the protocol or at least dbus interface. Otherwise, if you're writing some sort of automation tool, good luck porting it to dozens of different compositors. Key-value pairs are also important for said automation tools and different quality of life scripts.
The whole portals thing is extremely silly. If you have malware running on your PC, key logging or screen capturing is something you should be least worried about. But this stuff breaks a lot of use cases that are just slightly beyond the default "share screen" button. For example, steamlink-like software, which is remotely triggered, so you probably won't be near the PC at that moment to confirm the screenshare. Or having to re-confirm global key access after every bind settings change and after any update introducing new shortcut.
The ability to save choice and configure app allowlists would partially solve this issue - but this stuff isn't part of the protocol and is up to portal implementation. So we can absolutely expect GNOME making the most unflexible thing ever, and niche compositors creating 200 lines long configs documented in 3 lines of text on wiki. And there are definitely would be issues with saving default state for appimage and other containerized apps.
If you don't trust the application - simply run it in the container with display server connection proxy, filtering what it can access.
Just to clarify, I have nothing against using PipeWire for screencapture streams, it does a great job. But portals - questionable decision.
Obviously, blind hate towards Wayland is stupid and ultimately counterproductive. Especially considering that modern X11 is an absolute mess held together by some ancient dark magic, and should be retired as soon as possible. But there are still a bunch of issues, some of which for some reason are considered features. I do believe that being opinionated about software you're developing is a good thing, but there are times when it's not - and Wayland is a great example
A portal doesn't mean it needs interaction, we have lots of portals that don't. And at least gnome is storing what you permissioned and remembers it.
Eh people make mistakes and click things and run stuff even when they know what they're doing. If the default for third party apps is that they run with default restrictions, it can probably help people avoid problems when things start asking for permissions. But yeah it's just one piece of that sort of security infrastructure that will hopefully not be weaponized in the way it has been on mobile OSes as more of an intellectual property protection in a lot of cases. :/ If done well, it shouldn't break user autonomy but it'll be a lot of work to get it right.
It has been pushed when it's good enough for most people, and in the case of Xorg that is a necessity . If we are not strict, this transition will take 10 years more. People will find workarounds, or will take a step forward to implement them themselves and that's the whole point.
We must burn bridges so there's no come back. We could end up in an embarassing python situation if not. And no one wants to endup like python, right?
Having to still install python2 on every distro 16 years after python 3 was released is just stupid.
@@Aeduo If you want a third party app to run in a sandbox it has to be a full sandbox, and there's nobody stopping you making an X11 sandboxing module that sits between your sandboxed app and the real X11.
@@thewhitefalcon8539 applications fully sandboxed are inconvenient. That's why there are portals. So there's an intermediary between processes interacting with the system and each other.
Re: icons, ...also, you neglected to mention that the LibrePCB devs said in that thread that, because they consider the current approach unacceptable, their user-experience-focused solution was simply to take the same approach as the Dolphin emulator and lock their creation to "XWayland or nothing" semantics.
Wayland has a giant bunch of issues. But this anti-Wayland FUD site you quoted at the beginning needs to stop getting attention 😄
Image writing an article about how Linux sucks because of all these Wine problems, and you have a pretty good analogue for what is going on in his mind.
I remember that guy having some absolutely garbage takes about something else a couple of years ago, fun to see this hasn't changed.
Why did you skip the "Wayland breaks BSD" comment Brodie? I genuinely worry about the future of BSD when all apps starting to drop X support (which I guess is something dev don´t want to bother with when converting to Wayland)
FreeBSD and OpenBSD are working on support, it seems to work. But they do this by.. implementing linux specific api. So yes, wayland compositors are tied to linux or operating systems that pretend to be linux for compatibility.
@@notuxnobux I don´t know so much about where FreeBSD is on the subject. But OpenBSD, although there are a Wayland section (with a few things) in the pkg repo, I haven´t heard anything about Wayland in base from the devs. Remember OpenBSD ships with the rootless X11 fork "Xenocara" out of the box . And if I know my OpenBSD right, they wouldn´t touch a project like Wayland no matter how long the stick was.
@@michaelheimbrand5424 among the BSDs, FreeBSD has embraced Wayland the most, Hikari began on FreeBSD and not Linux. OpenBSD has just started work on Wayland and there has been a paper at EuroBSDCon 2023 3 months ago and over on the xenocara website Matthieu Herrb is working on porting Wayland, so stuff is going in the right direction. They'll definitely touch Wayland since they'll gonna deprecate Xorg too at some point and they'll also make a secure version (unless they want to keep maintaining Xorg, in which case good luck)
The BSD world has a couple of options, take on full maintenance of Xorg not just a soft fork, adopt the Linux APIs to support Wayland or die. It's not a good thing, it's not comfortable to hear but it's the truth
Yeah, that was probably the most legitimate criticism of Wayland, along with another one... that nouveau sucks. I do think Wayland will eventually be fine for Linux, but I run Solaris and an older nVidia card as well as Linux, and find it easier to just use X11 for everything for as long as I can... plus I have tons of Motif applications I still use, and I like things like IceWM, xterm, etc. X11 may not be the best solution for big DEs like KDE or GNOME, but if you just want a light window manager and a simple menu-driven system with a lot of terminals and clocks, as well as good OpenGL acceleration on nVidia cards once in a while, it's pretty good. Given that Solaris and BSD are still using variations on OSS rather than ALSA, I'm thinking a lot of alternative Unix systems may just give up and become command-line only, or else keep X11 on life support like they've done with OSS. I think my biggest pet peeve with Wayland is how Linux-centric the design is, when it's replacing something that was OS-agnostic. It's hard-depending on the Linux way of implementing everything from graphics drivers to DBus, and the more any OS tries to implement it, the more it will become a pointless clone of Linux anyway. Red Hat seems to have mastered Microsoft's "Embrace, Extend, Extinuguish" pretty well, extinguishing all non-Linux after bringing them all together for a moment with cross-platform standards. But arguably that's more of an issue with letting Red Hat run Linux than with Wayland itself as a concept. I don't like that so much of what's developed for Linux is pushed by IBM/RedHat to force uniformity on the ecosystem and kill off alternatives.
I'm pretty standard average linux user and I have no real preferences for X or Wayland but its pretty real fact that my linux workflow is not possible to be done under Wayland session. That's fact. 2+2=4 in X have to be the same as 2+2=4 in Wayland. If Redhat of other are forcing me to go with Wayland - I will left Linux because the situation in linux desktop in this moment is worse than 10 years ago
i will be honest: portals can absolutely be a pain to use sometimes. Especially when some update decides that your dbus activation environment does not set the correct XDG_CURRENT_DESKTOP anymore. (or not an update but you changing your config file)
They can be but this is a problem resolved with better code
The xprop/xkill stuff should be addressed by ext-foreign-toplevel-list, ext-foreign-toplevel-management, and ext-foreign-toplevel-state. Unfortunately, they're currently a mix of not-very-well-supported-yet and draft-until-the-other-stuff-gets-supported. They also seem to have no way to retrieve window positions, which would be necessary for the "click a window" interface of xprop/xkill, although a task manager style list should be mostly possible.
The IME functionality on wayland not properly working is still valid and it's the only thing that's keeping me from going to wayland currently. Even with environment variables properly set up for each IME through /etc/environment. With ibus on wayland if i change keyboard language to anything but english it still types in english. Fcitx5 is a lot better in a way because input methods in Group 1 do work no matter the language however if i switch to any other group it suddenly inputs only english as well even though the tray icon has changed to whatever language i've set up in the other group. I need to use groups otherwise switching between 5 different input methods in one group is complete confusing unusable mess. The same configuration works perfectly under X11 as expected for both ibus and fcitx5
wayland keyloggers are a thing you just need to source it with the login shell then it has the same privileges as x11 because there is no sandbox for linux only wayland has the sandbox and everything running on linux but outside of wayland is allowed to keylog everything the user that ran it does
Yeah, pretty sure the idea of Wayland is to be used alongside an application sandbox, which is incredibly hard to do in X11.
I thought pipewire just a replacement for pulse-audio? It's a thing I end up tearing out of my installs and installing plain old pulseaudio because with pipewire my audio doesn't work. 🤣
You made a typo in your description, you typed "creates" instead of "creator"
9:00 How do you handle permissions for an application written in an interpreted language, e.g. Python? For example, if you look at #6392 in the repository for the Pillow library, you can see that a Wayland solution for taking screenshots was not accepted because it behaves differently from every other supported display manager. Looking at the linked commit in xdg-desktop-portal, it seems that if Python requests the screenshot permission, it will be granted for all non-sandboxed apps. I can't find any place in the settings to remove this permission either. So much for a "secure" way to take screenshots...
Yep, centralized permission management without centralized app management is broken by definition. I think the general idea was to have distro developers integrating the permission system with their package management through portals, but I highly doubt this would ever be implemented correctly
One way to deal with it, would be allow to define something like "sub-applications", so when Python wants to ask for permission, it will send the Portal the sub-application it's for so Python only gets access when it interact with the Portal as the "sub-application".
But one thing i would worry about, when a application connects manually and pretends to be a specific "sub-application", but maybe there other ways for the Portal to detect a specific application, which can't be influenced by the Python application.
When i think further about it, on Python there is a easy way to deal with it, building a binary linked to libpython, like production version of Gajim.
Many / most apps written using interpereted / VM languages just include the VM / interpereter as part of the app. Minecraft is a good example, it packages the JRE directly as part of the launcher instead of relying on a system installation. (there is an option to use a custom JRE binary though, such as the system installation)
@@Rikonardo I think the idea is stuff like core distribution packages and applications that are distributed in present-day ways (that is, bare binaries/scripts) will be somewhat more "trusted", but third party applications like flatpaks and stuff would have no permissions by default and need to be granted permission to access things.
But yeah that still does make it a bit iffy for scripts one downloads and runs from the internet on their own. I suppose there could be special rules in place for different interpreters like python, perl, awk, bash, etc. that could check the process's properties to determine the path of the script being run and apply permissions on that sort of granularity.
I get a feeling the legacy-style multi-window proposals would be an actually good use for this repo
I love Wayland. Almost everything is better. Moving back and forth between monitors or virtual machines with different resolutions is SMOOTH.
Question I have googled my butt off, so please help anyone.
I am wanting to use fedora workstation. I don't like the layout and programs (well some of the programs). I'm using hyper-v but if another virtual is better for this I will us that.
I want to install on a virtual machine, make edits like say first thing change desktop looks. At that time I want to make ? another iso ? of Exactly my install. It will be only for me and only for 1 pc. Is there a way to do this? The end result is I'd just like to have a default bootable usb that will install fedora back to exactly how I had it. All programs, my files (pictures, etc..).
I really hope this makes sense. I just want to install what my system and it be right where it was at that point with all program files. Again, this would be just for me. One user, one pc, literally just for my studio pc.
Where can I find the podcast with Matthias?
I basically used wayland for a year, but after the nvidia driver update, it almost completely broke for my video card, so I went back to xorg for a while. I can definitely roll back the nvidia driver, but I'm too lazy. My main problem with wayland is that it is laggy on my nvidia card (except hyprland). But it worked not too bad on Hyprland.
as someone who daily drives wayland on an NVIDIA GPU, it's fairly stable and ive ran into few issues. mostly with applications which just somehow manage to break support for it, i alcan have more security, multiple refresh rates, and through some workarounds, I can record anything perfectly fine, wayland is very much useable and some people are simply too scared
The holiday season changes everyone, even probono
VokoscreenNG's "experimental" Wayland support works well for me on Plasma - at least full screen and window capture (I had some issues with region capture in multiscreen setups, but that's a hard problem anyway).
I'm all for wayland, but the nvidia issues in regards to explicit sync are just taking way too long to be resolved and looks like it will take even more time unfortunately ... This is by far the biggest showstopper for wayland adoption.
When in doubt blame nvidia
@@RomvnlyPlays In this case the issue lies on wayland, even if you are a nvidia hater. Explicit sync is the way to go, implicit sync was out of date before wayland even existed but wayland still decided to go with implicit sync, maybe because amd and intel only support(ed) implicit sync. So nvidia was ahead of time while wayland, amd and intel was outdated. Explicit sync is also the vulkan way. Nvidia has also provided code to support both, but those haven't been merged by wayland devs for 2 years now. There are also applications that have suffered from this bad choice by wayland, such as mpv.
@@notuxnobux too bad I hate nvidia and I blame them for EVERY short coming of wayland! 🤣
That’s how people be acting like
Thank you. A nice wood block puzzle project. #NewbyTreasureBox
I don't use a Novideo card and I also don't use Wayland
Me: Sees the "Boycott Wayland" post
Also me: *Aw shit, **_here we go again..._*
in my experience the only thing wayland breaks is discord screen sharing, which i was unable to fix personally but likely user error
for me it works when i run discord in brave.
@@upendownlinker problem, I run discord in discord
AFAIK there's still no solution to the global app menu which is why I won't bother with Wayland. There might be other issues but that's my dealbreaker for now.
Just found this out today when I was looking to configure waybar. Major disappointment indeed :(
"Global app menu is a security violation!" - Wayland devs probably
There is a “foreign toplevel management” protocol in wlroots now, for getting window info (like xprop), but compositors have to implement it. Also, I haven’t been able to figure out how to connect to it from Python yet. 😢
Wayland does not exist to me until unattended remote control works. If I WANT an application to be able to ALWAYS capture my entire screen there should be a way to "just do it". The whole new security thing is just wonderful, but there needs a way to get stuff done when it is needed. "Get out of my way, Wayland!"
that way is called X11
I love how half of these work flawlessly already if you just use portals and pipewire
Here's the thing tho. portals and pipewire, as software, they suck. also, they are very Linux-y, and there are other Unixes out there. not that Wayland cares about that.
@@AntranigVartanianpipewire ROCKS what are you talking about
@@AntranigVartanianMaybe they're Linux-y because they were made for Linux. 🤔
Now we just have to wait until those portals are actually implemented. Only kde and hyprland supports the global hotkeys portal
Atoms were awful in X11 design. They seem like a good idea at first but you end up having to read 2/3 atoms just to access a single piece of information consistently across WMs, handle all value formats separately, and then you also need to handle WMs that set none of the 3. I can tell this from having to read atoms for a single functionality once.
You have to consider the wayland equivalent, which is to use different wayland compositor specific protocols (meaning including multiple xml files), running wayland-scanner on those xml files in your build process to convert them to c files and then building those c files and then setting up handshake, with back and forth to the wayland server and negotiating protocol version then having separate functions to handle those different protocol interfaces since they all have different callback function prototypes and handling the resources you get in those. So 1000 lines of xml + 500-1000 lines of wayland C code for the equivalent of 20 lines of X11 C code.
These both sound terrible.
Atoms are just a way to attach metadata to windows. It could be implemented better, we don't necessarily need key-value string map. There can be an attached namespaces system with each namespace having strict on-the-fly declared structure, or something similar. But this system is necessary to provide a way for different apps to exchange information about windows without tons of overhead.
again a problem in which wayland design is not the only solution
@@notuxnobuxWe're likely talking about 10 additional lines of C code because it'd be a single protocol and a file copy. Most of the properties I found are already part of the spec in some way a d have stricter semantics attached to them.
Moved back to x11. Funny how things started working OOTB. File explorer no longer hangs because of some d-bus issue, screen recording with audio is just working, don't need to pass extra arguments to run electron applications. Oh and I can run my videogames.
I haven't understood why the whole permissions headache on Wayland for screen recording and global hotkeys is necessary... Windows gets away without requiring annoying permission management if I want to screenshare on Discord or Zoom. Why is this being pushed on Wayland?
Because the Wayland designers are extremely opinionated. Part of the reason they wanted to make a whole new protocol was to make these permission checks a thing. You can't tell them they're bad permission checks.
"The window manager is not a sandbox" is a great sentiment for people who don't know about desktop session attacks... either that or the Boycott Wayland guy genuinely thinks the word 'malware' is a slur and that applications have a right to keylog your system.
So i want to shift to wayland but since redshift doesn't work i can't.
Issue: Screen is yellow (MSI displays on laptops) even at 6500K.
kde plasma only allows 6500K as the max temperature limit as far as i know. So to add more blue ligjt i am currently running a redshift command on user login.
Even the grub is yellow so yeh idk maybe its the display caliberation or something. Anyways i haven't really found any clear solution for this yet that would be as easy as redshift to implement.
That sounds like an issue worth reporting to KDE
Why do you use Alacrity? Its a half baked terminal. The dev refuses to to add common ANSI Escape Sequences like blinking text.
It's a terminal, it does what I need
Gotta appreciate how modular the spec is huh?
What font is brodie using for his terminal? 9:11
Jetbrains Mono
I dont understand the details of wayland, but when i failed to share screen with teams/meet and every tutorial is saying to go back to x11 the only thing that came to my mind was wayland is bad, like, i understand things should move forward, but if you're gonna make something "break" i would argue you that is a bad first impression.
That's the thing why many people dislike Wayland, and rightfully so, imho. a protocol that doesn't include important functions that a lot of people use (and I would say screensharing is not at all uncommon) is just bad.
The solutions are in place, the issue is many apps haven't made use of them, for the time being there are workarounds like Xwaylandvideobridge but it's very much a hack workaround
that's why I am concerned too, if the solution is "go back to x11", because gnome does not want to implement something useful, and now we have a situation where x11 will not be available to go back to, how are we supposed to work on linux?
@@_nishantk_ GNOME is only 1 party and often times they get ignored, they don't control what happens in Wayland
@@BrodieRobertson I sure do hope that, and that's why I use KDE, they have more useful pathway to wayland transition IMO, but GNOME sure drags the discussion for no reason at all
Re: xkill, as someone who hangs out in the comments there to counter the most ridiculous misconceptions, I can say that what he's talking about is specifically the "Push a key combo and then click the window you want to kill" user experience. People have come in saying you can do it and giving examples, but, in fairness, none that I remember has yet demonstrated how to achieve the "pick what to kill with the mouse" part of it.
I understand the reasoning behind the move toward Wayland, I also understand that many if not all the claims of the discussed blog posts are wrong - at least for me as a user Wayland does not deliver a worse experience than X11 does, and if screen-sharing did not work, Wayland would have become a COVID casualty - obviously it does.
But I also rely quite heavily on the networking capabilities of X11. I.e. I run X11 applications on Linux server systems by using a local X11 server on macOS or Windows or even another Linux machine running a desktop. Wayland has dismissed to offer such a networking capability right from the start (or didn't they?), as if no one needs it. VNC is not the same: to use it you need a full blown up desktop system on the remote side. Which these server systems intentionally do not have installed, resources are there for server processes.
And then there is this "Wayland is for Linux" approach, that leaves alternatives like the various BSDs behind. Given the people driving Wayland development are the same that had driven development for X11 lately, how do they justify that?
"Wayland breaks window managers" is hilariously stupid! 🤣I used to be a big fan of Plan 9 From Bell Labs, an OS which is rather impractical for compatibility reasons, but fans love to have ports of its userspace. Under Plan 9's window system, programs by default use the window they are started from; they cover up the terminal. There is no way to emulate this in X11, but there has been a Wayland compositor doing it for years. I forget if it's called rio, 8½ (after current & previous Plan 9 window systems), or maybe 9wm or something.
the day that flatpaks , snaps or whatever become a requirement , im switching to windows
You are welcome to BSD-land. Oh wait... Yeah, sorry. When Linux goes full wayland, BSD´s will probably be left without many important apps. Pretty sad stuff this.
@@michaelheimbrand5424BSD supports wayland
The idea in flatpak land is that that will never happen. Snap might do that.
They'll never be a requirement but you may find an app that you want to use that is only available through one of those solutions
Nobody wants snaps but canonical, but I'm pretty OK with flatpaks for large applications. I'd rather get the first-party build of particular applications, and it also makes it muuuuuch easier from a development standpoint to distribute one official binary that could be far more universal through flatpak, rather than have to provide support for various distribution packages that could've introduced bugs for various reasons. But yeah I do prefer if stuff like the base system and desktop environment and the basic desktop environment applications/tools/etc come from the distro. Kinda like the classic Windows approach.
"Many of you probably heard the name..." oh no, please god no 🤣
I knew someone will make this, wish good luck to the dev!
The dev is a known idiot wish him better mental health
The project description has an "But... Security" section that seems to imply that security should only be done through explicit sandboxing and that everything being insecure by default is just fine.
Apparently, the thing that basically all user interactions happen through is not the place to care about security...
the thing with portals is as it stands, you can't log key inputs and send them over the network hoping to intercept a password, but you sure can copy the user's home folder and send that instead, which for most users will include info from their password managers
now UNIX-likes actually have a great permission system in the form of users and file permissions; so you can "sudo -u untrusted app" and avoid the above problem, which if you care about security you must always remember to do, regardless of whether portals exists
so, given that we already have a perfectly serviceable permission system, that stays out of the way of security-apathetic users and that security-conscious users are forced to use no matter what, why on earth does wayland make its users use another one, with different rules, on top of it?
@@yjlom Because accessing the users home folder and logging all their keys/screen are different things, that both need to be addressed.
Maybe if Unix ever came close to the promise of everything being a file, there might be some point there, but as it stands, the down locking access to the file system does not help with non-file based apis, such as the ones that seem to be proposed.
One security issue does not justify adding more, and it's not like there aren't also efforts to restrict file system access.
@@yjlom Yeah, having some kind of separate user context and application contexts would be good. I dunno about making each app a separate global user though. That just strikes me as kinda sloppy. I'm sure there's a better way for the kernel to expose different filesystem access to the same user's files on a file by file or location by location basis as approved by the user, like through the standard file dialog boxes or drag and drop or requesting explicit permission, and maybe default permissions for the application's own XDG directories.
@@Aeduo Isn't that just containers?
@@Poldovico I imagine some of the same technologies would be involved but containers seem to be fully individual file systems/Linux userspace installations in most applications of them, so they would be conceptually a bit different than that.
screen capture through portals is not perfect, every time I start up OBS, I have to re-pick my screens. That's awful.
4:15 you misunderstood what that means. For example in the desktop portal for screen capture you need to depend on pipewire. Not the desktop portal itself, but your program. Each application also need to write 2000+ lines of pipewire code (which also uses macros that are non c standard and give you compile errors if you compile without allowing warnings). The X11 equivalent code is done in around 5 lines of code with no extra dependencies.
Wlroots is actually one wayland compositor that does not require dependency on pipewire to capture the screen. You can use wlroots specific wayland protocol to capture the screen directly without any permission and without any extra code. Note that permissions could be added to this without depending on pipewire.
And we cannot wrap these 2000 lines of code in a single reusable pipewire based library because...?
@@wertigon If you want to make it generic enough as a library you need to write way more lines of code than that. This is just the bare minimum to get it working for your specific use case. But you are free to try and write those ~10 000 lines of code + tons of extra dependencies when they are not needed in the first place. Nobody else has done that.
WLR_Screencopy protocol is very messy, is slow and is not the better way to handle screen buffers.
@@ratatouillegamer7132 I dont mean screencopy protocol
why not adopt pipewire???
not have reason all distros is changing for pipewire, and pipewire is very important not just for audio and screen buffer handling during screencast/record but too for LibCamera, LibCamera is very dependent and pipewire can help with this.
In case of Direct Scanout Pipewire can copy all using dma-buf and allow to use a wayland sink from GStreamer for output without need for compositor handles this during composition, allows to a minimal energy usage.
About Screenrecord is really possible to handle all using blitter operations for copy all buffer to Pipewire instead of compositing all screen
I really don't understand why so many quite important functions have to be implemented via portals instead of being part of Wayland by default, available for everything that uses Wayland. Apart from that causing "reinventing the wheel" over and over again, the "security"-argument doesn't make any sense either. If the Wayland-devs say that implementing something could be a security-risk, but then said functionality is implemented via a portal, the security-risk is still there, just not in Wayland itself but in the portal. So what is won?
The security risk is not there. There is no user interaction with Wayland protocols. Portals require the user to give explicit permission to a program just like how android/iOS handle program permissions
@@PeakKissShot Hm, I'm still not convinced. The security risk may not be in Wayland directly, but it could still be in the portal to do something nefarious. Wayland may not be at fault then, but the result is the same, as far as I can see. But I'm not that much of a programmer, just a hobbyist, so I may be missing something.
Anyhow the permission system could be used directly in Wayland as well, so I still don't see why portals are needed.
That's part of why it's in portals. It's a separate thing from the compositor itself that doesn't need to be implemented multiple times, and the idea of the portal would be that the portal could reject an application's access based on the user's configuration or when indicated by a user request. But yeah overall it probably is to keep the individual components somewhat simpler. If it doesn't have to do with window management and driving the display, it can be in a separate component than the compositor.
@@Aeduo Thanks for the explanation. I think it could be separated just as well if integrated into the main project, but oh well. The decisions are made I guess.
If the underlying frameworks break those things on top of them... it is the frameworks' issue. Not the dependency's. Linus has a pretty strict "don't break userspace" rule for a reason.
This should be easy to understand... libraries and frameworks are designed to be used by > 1 dependents. As that 1 to many dependency grows it becomes increasingly important to keep the contracts in place. The cost of breakage is ever increasing. It is easier to write 1 back compat layer than it is to rework the many dependents.
If there is absolutely no way to provide backwards compatibility, fine, but that seems pretty unlikely to be the case. Even if imperfect... something working but slow is better than not working at all. Leaving users and developers out in the cold... told to spend their valuable time fixing things effectively broken upstream... is not just inefficient it is also extremely inconsiderate of other's time.
4:20 recently I started running Haiku on a thinkpad and it surprised me to see that now even Haiku supports dbus. At this point this dude is just screaming that he hates change.
Welcome to IT, hell even I'm guilty of it at times though sometimes the complaints are justified to a degree you also have to accept that certain changes are necessary to improve elements that are important, in this case a lot of his complaints are about changes that definitely benefit security which used to be one of the chief selling points for switching to Linux, enhancing your security.
Wait.......does this mean pipewire will handle obs's virtual camera?
Yes that's the eventual plan
@@BrodieRobertson that sure sounds awesome
looks like windows have the same problem of only one app being able to use the camera at once... i have no idea .... WHY!?
Yeah it's been a thing with audio and cameras for a long time on Windows to varying degrees, audio has gotten better somewhat but in both cases the workaround is the same using a virtual device as a passthrough. Which you'd think with something that's been a headache for decades might have been done via the OS itself right?
5% (maybe 10%), of that post is actually wayland problems (nothing that can't be worked around), 50% of it blaming wayland without an actual idea about who to blame and rest is that "My DVD player can't play cassetes"
o what did probono create today
Android & iOS having a permissions system like that is why using Android & iOS sucks and cant do half the things you want to do though...
I'm gonna make xorg 2.
It'll be a clone of the wayland repo.
Wayland still has some problems but it still remains a net positive in my book. This does not however justify spreading false information. The occasional freezing of the desktop i get is probably more the problem of Plasma, but Wayland. On the issue of high resolutions on external displays, i'm not sure. Also the horrible performance on DualGPU setups, especially Thunderbolt eGPU seriously needs a proper fix in Wayland. But the added flexibility and overall better performance compared to X11 make it still worth using imho. Where it is problematic, i can just switch back to X11 by logging out and starting another session.
9:11 nice neofetch
7:47 the application itself doesn't need to support pipewire to make this happen and that would make it much easier for applications to support wayland, but wayland devs still agrees that desktop portals should depend on pipewire, making it much much more complex. It's just a bad design choice by the people involved. It's generally a terrible idea to make your protocol depend on third party protocols that might be replaced in the future for a better solution.
Bad design??
is a secure BASED design this is not to be a Cringe Bluepill Xorg Boomer thing
And if this not user pipewire for getting buffering from frames what will be the way to handle this?
@@ratatouillegamer7132 CZcams deleted my comment again..
dependency on pipewire here is completely unrelated to security. The security comes from the permissions which is part of the design of the desktop portal protocol itself (because of waiting for response). The proper way to do it here is to the it the way X11 does it, by having abstract resources. Instead of having a pipewire node you return an abstract resource that you then use to request the data (or direct file descriptor, depending on which is best for your os). There are already other desktop portals that work in a similar way to this.
@@notuxnobux the worst part is how ppl act like the wayland design is necessary to solve this problem, it is not
New name proposal for the "Wayland X11 Compat Protocol", 'XPat Protocol'
Not related but I always laugh about how Americans are never immigrants they're only ever expats or ex patriots
Developing a new Wayland window manager based on the XPat Protocol: Thailand
Should have called it X12 instead of wayland just to mess with people like this.
"Wayland isn't the problem."
"All your other user apps are the problem!"
Great argument /s
When a solution is available and the apps don't implement the solution then who is at fault
@@BrodieRobertson Ahh ya... break it... and then do it my way or the highway. Again. Great argument.
And listen... I don't disagree that Xorg is old and creaky, but what happened to not breaking user space? What is wrong with incrementalism?
@@coolworx The Wayland devs weren't interested in doing things incrementally, but no one else was offering a solution. As for don't break userspace, this is specifically about the kernel. Whether this is a good thing or not is another matter, the only people who want to do this work made a choice so that's all there is to it
I just have a temporary system wide portal function I stole from a codeburg compositor and allows for velox to have waylands performance with xorgs convenience without the "security ". The original project is adding granular security via apparmour but really cant be bothered.😂
Like absolutely concede that there are gaps in what XWayand supports and those should be addressed before X11 is entirely deprecated.
But c'mon man...
What is even a portal?
I think it is a good idea. This could be a community standard without monopoly of Wayland devs. It's also needed that all other DE and compositors (except Gnome) participate in writing and implementing it.
I am so fing sick of time/date displays. I guess they assume every user is so mentally deficient they can't understand that, for example, at the time of me writing this, 8:02 was 3 hours and 38 minutes ago, that somehow writing "2024-01-01 08:02" is going to take me minutes to figure out. Just put the damn date and time you want to convey on the page and let the user figure out how "ago" that was to the user's desired precision.
I like hearing that name (probono) again, while my Xorg setup currently shits itself, and Hyprland works rock-solid... On a 2060 Super.
Have to use hyprland ig, until I have XFCE on Wayland
isn't this the same guy who was whining about distros not shipping fuse2 because he couldn't be bothered to switch to fuse3?
Why do people insist on defending a dead project like Wayland? It's never been good, it'll never be good. And I like how you skipped over the nvidia problems.
It looks pretty alive to me, as for the NVIDIA problems I skipped over a ton of other things that's one of the things that is actual problem but is slowly being improved
[ ] Screen Recording without portals (because security is harmful)
I think someone just have to start fixing and start using it. If say KDE just desided to start supporting one window placement protocol - after the forever discussion that always gets blocked by GNOME, then it would likely win out,
I'm getting the impression that is what the Wayland devs want. They want protocol extensions to bubble up through the community, so they can adopt what people agree on using.
They even have a Wayland optional protocol space where no WM can veto
You can say all you want, but still:
* there are lot of issues of global shortcuts not working in wayland;
* there are lot of issues of screen capturing not working in wayland;
* there are lot of issues with windows positioning in wayland.
Wayland is more than 10 years around, and its still at "basically works" stage, without any visible benefits but with problems. For now X11 works just fine, and does all its need. Wayland sometimes works, sometimes dont.
So... Why I should bother with this fancy-shmancy thingy? Whats the benefit of going through this hussle? Instead of running everything inside of XWayland, isnt its just better to use old X?
Hyprland had it's own workaround for global shortcuts it's one of the reasons I run it, window positioning is still an issue
@@BrodieRobertson but why? Why change working system to not working one?
@@Zzzzzzzzzzzzzn because the devs feel like a better approach can be reached
@@BrodieRobertson but its not better from user perspective. For now it just worse. There are no immediate benefit, but there are immediate problems. Why me, as a user, should do that switch?
@@Zzzzzzzzzzzzzn You don't have to switch right now if you don't feel like it's ready
Matthias Klumpp is such a king
did someone say wayland?
Does wayland kill my kitten, destroy my house or start a mayan apocalypse?
all three...allegedly
BTW, some starting youtuber called ProtonPenguin starts off with trying to 'debunk' this video ;)
I have a perfectly functional desktop without Pipewire or Portals, so no, those are not like libc or the kernel. X11 applications require permission to run on the display server at all, so that includes screen recording. An application that is going to screen record behind your back should not be running at all anyway, unless you're doing malware research or something similar but that does not apply to most users. Personally, not a big fan of d-bus but that is indeed almost a necessity. We don't need to add more bloatware as "basically required anyway".
There's a German saying describing that kind of attitude: "Wash me but don't make me wet".
i am tired of how the wayland project is governed. nobody should be able to limit features in a desktop experience in the way the wayland maintainers do.
it is a mess, and it's a nightmare that you have to go and fucking fork wayland in order to make anything work in projects you're making. desktop features should be generic, and work with every application, even if it doesn't make sense.
i value the ability for different people to have completely alien workflows over maintainers' and developers' opinions on how software should be used.
wayland should not be able to just nack things and lock them into being stuck on one compositor, even if it's vital feature for some applications to work
no global keyboard reading means no stenography! (plover does not work on wayland)
no multi windows means no scientific apps!
thr maintainers' opinions get in the way of making applications with certain feature sets that other platforms take for granted. it is a nightmare.
it's the same bureaucracy that limits flatpak to be desktop applications first, and forces you to adapt to *their* workflow to do anything in the terminal. applications should slot into *my* workflow. *not the other way around.* this is a nightmare
To be fair, they *can't* there's no reason a compositor can't just implement it's own wayland protocols. But then it becomes not standard. So only that compositor (and compositors that can be bothered to implement it) support it.
This is why design by committee is annoying when you just want to get things done.
wayland is like nvidia 😂
@@Sekhatt that's the problem. the standard isn't a standard! it's not generic at all and doesn't support all apps, and on purpose