One thing I completely forgot to include is qtile, this is a window manager that actually did build a Wayland compositor alongside the regular Xorg version. As I said that it can absolutely be done but many project aren't going to take on that task.
My take on it is that if a project was started with the goal of supporting both, it'd be rather easy over time for them to achieve that goal. But most projects are started with the idea of only targeting one, so they don't bother to understand the other and as a result the implementation and end users suffer. Understanding the differences is part of what makes us and the software better. The same method of development should be applied everywhere, and if it were, Linux would be an overnight success because game developers would be better at targeting it.
I've been trying qtile just this week, and although the Wayland version works, it doesn't feel as stable as the Xorg version. For instance, it logs errors about elements or functions not being available, even though I'm using the default config. And then there are glitches like not being able to use menus in applications, or sudden dbus errors shutting down the entire WM. So this seems to prove the point implementing Wayland is hard, if not for the initial implementation, then for ironing out the bugs.
Seems like something Redhat should tackle. They handled pipewire really well and it most certaintly helps having a large structured company with plenty of well payed workers.
I’m not sure how such a project would fit into RedHats business model. ROI for example. You’re probably right, though, this might require the involvement of a larger scale development team working full-time.
@@donaldmickunas8552 maybe it can be like glorious eggrole and a single dev or a few devs work on a simple compositor, but yea I can see them not bothering as a company.
Well, wlroots is meant for this exact thing. It is a modular Wayland compositor meant for building custom compositors. So that is what Wayland window managers should be using as their core. And work on improving together if they think it's insufficient. Great to see that Sway is creating an easier API for it. I bet this will lead to a lot of new Wayland window managers. Anyway Brodie. A year ago I never liked your videos and thought you were waffling without much info back then. But nowadays you are by far the best Linux creator on all of TH-cam. You are very knowledgeable, you have deep understanding of both the user and developer sides of issues, you always avoid FUD and drama, and you have great presentation skills. I don't know how you did it but you are now the only person whose videos I always watch. Super great job, man!
Regarding your second point, yes, I have to commend Brodie for finding, researching and presenting good, relevant topics. Actual good journalism work over here.
You can make a full windows manager for x11 in 20 lines of code (with no dependencies besides xlib). Even with wlroots, it takes around 2000 lines of code to get feature parity with those 20 lines of code.
This reminds me the situation with Vulkan vs OpenGL. Compared to OpenGL, Vulkan requires much more boiler plate code and a lot of work just to draw a triangle, but once you do the legwork, it gives you much more control and performance out of your hardware.
I think your point is well-made, Brodie. I've been looking at porting fvwm to Wayland (which is laughable -- it's going to be a rewrite at best) -- and because of how disjoint everything is, in that compositors are now their own server as well, the mapping of features from X11 window managers to Wayland compositors, is either very difficult, or non-existent. For example, in fvwm, the window borders and title will often look similar to MWM, which has a 3D-effect. This is something a Wayland compositor would have to do via SSDs. However, to do that, third-party libraries are required to now draw and style the rectangle. Unfortunately, this boils down to either using libcairo, or using my own library (unwritten). libcairo does not support the requirements at all, so themeing is a no-go in terms of translating key features from X11 -> Wayland. This is fundamentally due to the fact that X11 was responsible for drawing all graphics, so there was a great deal of flexibility there -- but until third-party libraries such as libcairo offer the same functionality, this is going to be very tough for certain WMs to transition to Wayland, whilst keeping their core feature sets -- these are, after all, why users continue to choose these niche WMs in the first place. As for wlroots -- it's helpful when removing the boilerplate code, but even that has certain subjective ideas which are hard-coded.
I think you'll see a few major compositor libraries and then several compositors which implement their own libraries. I don't think you'll see a single defacto library
@@monkev1199 after leaving the reference standard Weston behind we did multiple libraries but over the years we've been converging on 3 core choices GNOME, KDE, and of course wlroots
As long as GNOME decides to actually rethink its extensions. Because right now mutter and wlroots apparently are causing fragmentation. Just look at CSD vs SSD for example.
For better or for worse, Wayland is forcing a process of standardization through association that takes more effort and coordination than just implementing an Xorg compositor, but that at the same time gives you a lot of freedom. So in the near future we will have GNOME/Mutter, KDE/Kwin and WM/Wlroots. If you wanna make a new project instead of reinventing the wheel, pick an option.
At the same time GNOME, KDE and wlroots don't support the same extensions for the same task so that's causing fragmentation. Or is GNOME causing all this mess?
That was actually an interestring topic. Yes, you have to do much more stuff to create a wayland compositor than a X11 window manager. But because of an intense wlroots development, this complexity was regressing recently. At the begining of this year I've forked a dwl to create a compositor which looks more like a dwm. And it was horrifically resource-hungry, because of a simple-but-clear render logic. Not long ago I've updated my compositor with a new wlroots version, with a scene-based render, which actullly fixed a problem with a resource consumption, while made the code more clear. So, while wlroots progressing, I think it will move us closer to the situation, when developing a compositor will be as easy as a developing a window manager.
actually I feel it's the opposite. The window manager scene has been dead for at least 5 years. Gone are the days when every couple of days a new window manager appeared. Now with wayland and wlroots there are quite a lot of small little compositors that it actually feels a bit like 2010 again. So yeah, it might be harder to create a wayland compositor, but projects are actually happening which makes the linux landscape feel a lot more alive again.
Most people are looking at already existing manager instead of new ones. Aka they expect the devs of existing managers to create essentially a second manager, which is ofc something they will not want to do. However, other people want to create their own project which is happening rn in quite a large amount.
I think people are making new window managers, because there aren't as many good ones yet. For xorg there are tons of great window managers, there is no point in making your own window manager in xorg, other than for programming practice. For wayland only a couple good ones exist, there are certainly still people not perfectly satisfied with any one of them.
Qtile works on Wayland, they managed to port it quite fast. Awesome works on Wayland too, right? i3 works for sure. I think that covers most people. Sorry Ratpoison enjoyers, your WM has been dead and irrelevant for the past decade
@@spicynoodle7419 QTile has a Wayland Project. Awesome most certainly does not work on Wayland and attempts to port it are long abandoned. i3 also does not work on wayland but there is a similar WM called sway which is built for Wayland. Things don't just "work in wayland," they have to be rebuilt from the ground up, and the ratpoison is tasty and helps me stay thin.
I, for one want wlroots and Wayland to succeed. Wayland is still relatively young, and I wholeheartedly expect it to take off at some point. it's a whole lot better supported than it was when it first came out. Especially on my hidpi machines, I use it over xorg any day. We may lose some old window managers, but there will (hopefully) be a viable replacement for it, just like sway did with i3. I also like the really cool concepts that some wlroots managers have come out with, like newm for example
Coming from gnome and switched to hyprland as my first tiling window manager. Nothing feels better handpicking and cooking your own environment tailored to your workflow.
Great video with great explanation of the issues, as it also fits into the idea what I got about Wayland from other information sources: Basically the whole point behind Wayland was actually to make it kind of as small and simple as possible, to remove any extra functionality from it (compared to the monstrous X) that the compositors themselves already do. I can totally see how for the smaller compositors and desktop environments that exactly can be a bigger issue. Because they where performing the same job of simplicity and minimalism as well. Functionality needs to come from somewhere. Having a helping library (like wlroots) can help indeed. But there's one caveat: the chance that this eventually might be going to be bloated again, because, once again, it's complex functionality, but just on on another place (in the library). It needs to be extremely well designed from the start.
Among the "simple wm", qtile did it. On the main repo, not as a secondary project. I havent tried wayland version, there are for sure issues, but well the most is there
I feel like Xorg and Wayland are built so differently that rewriting from almost scratch might be easier and more efficient for some projects than porting Xorg codebase and make it work
I'm embedded Linux developer. So I've done plenty of x window management and other low-level x calls. I can't imagine having to do everything that x does. Wayland seems like a nightmare.
ppl are working on libraries now. it will take time. old X was quite messy. it also had not many library. weston, sway, wlroots all working on and more will join them.
I would give the current Wayland team a decade at best before their complaining about how big Wayland is after every Wayland render has implemented 2/3rds of X11.
Sometimes I feel like most of those small WMs could be implemented as a river WMs instead of a new compositors, obviously if you have a WM that does something unique it may be not enough. And even tho I have my own compositor, I really enjoy the possibility of creating a WM in an hour or two in river, it allows you to experiment with ideas really quickly.
I had heard that wayland was trying to be minimal but had assumed it would have registration points for the various parts and prebuild libraries for each registration so there would be a "Default" wayland setup and then you can replace each library to fit your needs but hot damn this explains why wayland support is so atrocious
It does seem like Wayland needs *something* for devs to latch on to. wlroots is that thing in a lot of ways, but from what I'm hearing here it's very low level and a lot of work. Maybe an "easy mode" API in wlroots is the answer, maybe its Wayfire, or maybe something like DFL libraries the Desq project started if those happen to get any traction.
The easiest way to understand what the problem is with Wayland is to dispel a common misconception. There is no Wayland display server, it's not really a replacement for Xorg at all. Wayland is nothing but a protocol. The reality is, if your system is running "Wayland," the Wayland team deserves very little of the credit. All of the heavy lifting is being done by the Linux kernel's display drivers on the low-level side, and whoever wrote the compositor on the other. Wayland only standardizes a protocol compositors and drivers should use to talk to display devices. That is pretty much all it does, and it doesn't even do a great job of that... there are tons of vendor-specific extensions. They just decided to call the new thing Wayland because people would have been mad if they had just straight-up told people they were taking away the X server and requiring the kernel and compositor to step up and fill the void because they were sick of the responsibility, but that's pretty much what the developers of Wayland decided to do. To get out of the way and tell everyone else relying on them to figure it out for themselves, providing little more than a vague protocol that is a pale shadow of X11 as guidance or assistance. Linux was always GNOME-centric, but I feel that problem will get even worse now, because not everyone has the skill to write a good compositor, and GNOME will write their compositor only for their own needs, and there won't be something more general that any Window Manager or GUI toolkit can tap into. They basically decided that if you don't have the skill to write your own compositor on par with that of the major DEs, then well, it sucks to be you, but you don't get a seat at the table anymore and choice/freedom has to take a backseat to security, tighter integration, and speed, which all also require more centralization.
Well, which of the points is "misinformation" to you? To my eye the following statements are true: Wayland is just a protocol, doesn't provide any APIs or libraries. If you want to write Wayland window manager you have to implement the protocol, which is the equivalent of writing a WM and an X11 implementation (basically an Xorg fork). Doing that requires a big team of professionals and realistically only big organizations can pull it off (GNOME, KDE). Sure, if you a small project you can use wlroots, but we have to remember, that it's not part of wayland standard (just another implementation, not an official library), and we have to be greatful for its existence, because that's the only one realistically possible way to bring WM's to wayland, but it can't address all of the shortcomings of the standard. In my humble opinion, as a soon to be future standard wayland is a dumpster fire. And if nothing changes, personally, I don't think I will switch from X11, despite its shortcomings, it's actually "workable" standard and Xorg is a solid implementation.
@@LA-MJ I already gave it the amount of time it deserved. If someone is willing to engage in that much vitriolic FUD, I doubt that their minds can be changed. I get it; some people hate Wayland. That is a very cool and unique opinion to have. 😂👌
Projects like wlroots are the solution for this. A plugable compositor for wayland based operative systems, where the devs can just enable or extend the subset of features they want. This approach have some great adventages, for example, there are features which are not easy at all to implement (vulkan support, color management, 10 bits, HDR, multi-monitor extended window...). Imagine if every OS had to implement this by themselves. They don't; They just use wlroots.
I guess you could describe the change as some vertical integration between the window manager and display server which provides more flexibility by virtue of accessing both systems in one process
it will take a time. I don't think existing wm will port to wayland but new wm will be created by many other people. a lot of library will have to be made before that. weston project also is making libraries. with enough of library, a lot ppl will work on new wm.
I am kind of confused now, as a user I thought Wayland was easier for devs to implement and maintain while I cope with the mess. Now it just seems like the mess is on both sides.
not quite true. X is mess and bloat. but it is old project. X have tons of library. wayland is pretty new project and they don't have many library just yet. that's take a time. weston and sway are developing libraries. that's good sign. wayland protocal has been pretty stable. soon we are going to see a lot of new wm. I'm pretty sure of it.
@@MrjinZin0902 I am not sure if I should be glad on that one. I want to use input-synaptic but it seems to be quite locked down on libinput, which also needs to be separately implemented by the compositor. And I hope they have plans to unify the extensions or we will end up with 3 factions with software that won't work on others.
Wayland problems are still very much a thing. One case I had just a few weeks ago was that I can not screencast with most software due to all of the changes. I get that it's necessary to fix the security issues with X but no one is interested in porting their software over to Wayland.
i think the best path forward is something similar to X's situation, where people simply use wayland as the display server and literally just write seperate compositors and WMs for it it's just that the compositor has to do so much more now
You can't really do both unless the implementation designs around a seperate wm and compositor process (which would be great for robustness). The die has been cast on the public api side and any real effort has to go on the server side.
Such a gambit of many things. Wayland has become easier to use. My desktops are xfce and kde. I love dwm and icewm. Wayland has improved in terms of setup and bugginess. Development wise we're still looking at some time before it becomes official. A lot of will sees. It seems like most old software will fade away and the new will be developed and its own thing. I think it's still very new and seems to need to develop more solutions to Wayland with the components under the hood.
I'm wondering if we'll see a compositor at some point which recreates some of the plugable behavior of X, such as window managers. It would likely be much easier to port a window manager from X to such a hypothetical wayland compositor than it would be to build a compositor around a window manager.
i d still want a working PAM module that i can actually operate the way it used to do before the project was discontinued. PAM was one of the best linux modules, but it has been deprecated and changed in a way that makes it impossible for a normal user to set up properly for say: USB-stick oriented login access. please anyone who got that set up properly under wayland or later ubuntu versions, show me how...
On my kde arch install the custom shortcuts aren't even available on the wayland session. It took me hours of research before I realized that I was in a wayland session. When I switched to X the custom shortcut menu was present. Also my presets in "easyeffects" didn't work in the wayland session. but do work on X.
I'm very annoyed by the way X11 has been treated. X11 is a protocol, and while it has some issues because it puts the dividing line between client and server in not quite the right place, I see no vision for what to do instead that has anywhere near the flexibility. I discovered a long time ago that GNOME/Gtk basically completely tossed all the features of the X11 protocol in favor of just capturing every possible event and doing all of their own drawing. Of course X11 is going to work terribly when you do that. *sigh*
I'm still confused on why no one is making something like X12... Or something like that and streamlining X11 with bugfixes, removal of old code (that in most cases nowadays is considered bloat) and mostly keeping it indeed usable for WM makers...
@@BrodieRobertson spiritual, but I mean like the same codebase but adding things to it and keeping it as a display server and not moving the compositior to a different program, as in the DE itself... If someone is able to write efficient code that can be moved into X itself then you can call upon X features (IDK how it works but this is how I think it does) and activate "X12 extensions, functions or services" that have been added or replaced current X11 functions. (that wouldn't be me since 1 I can't code in C, 2 python and JS I can kinda code in but I totally suck at it and 3 programming isn't my interest.)
@@imtiredtoday Check out my history of X video for the full story but prior versions of X were traditionally not compatible with applications from the earlier versions
There are notes for a proposed “X12”, which you will find on the xorg site somewhere. That’s been knocking around for years ... decades. The trouble is, X is full of legacy baggage (like graphics rendering calls) that needs to be dumped. At one time it even provided a font server, but luckily they were able to get rid of that. Once you remove this stuff, you realize the basic architecture of X, which allowed for having such things in the first place, is over-complicated.
ive tried to take up the task of continuing way-cooler, one of the attempts at getting awesomewm to wayland, and basically given up after being advised that its a futile task
I've tried everything with excitement... But I always end up back with my vanilla dwm... It's everything I need and want... Nothing more, nothing less...
According to the Xorg Foundation, Wayland is just X12 under a different name, and like Wayland, none of the previous X protocols were backwards compatible.
Ah yes... The fruits of the "we define only a protocol" fallacy. Same thing as with X11. Initially it was only supposed to be a protocol definition. This let to initial waste of efforts by multiple vendors to provide different implementations. Later everyone got so annoyed by minute differences between the different version, that more and more applications just went over to windows. After some time all the different vendor specific implementations of X11 got basically abandoned. So for a lack of alternative Xorg remained. It mainly remained because there wasn't anything else around. However it was still a rotting away project. The same future is awaiting wayland. With one important difference maybe: Vendors don't even care about it initially.
I loved E17 and Enlightenment. I used them way way way back when they were new and shiny and alpha. WOOF. Sexy accelerated eye candy of the time and I miss them. Someone has picked up Enlightenment but want to get paid to work on it. When I'm rich I will feed anyone working on enlightenment.
Wayland is just another try to copy what Plan 9 from Bell Labs did decades ago. Hint: what is missing is not a feature of the Wayland, is a feature of the OS (private namespaces (mount namespaces in linux) being actually used and useful). Plan 9 solved the capture problem by creating "device" file (not exactly that, there's nothing like "device file" in Plan 9, files has a whole different meaning) for the image, maybe the solution is to create these char devices for wayland and use UNIX permissions to tackle the security.
@@lawrencedoliveiro9104 Its only Rio. For each window rio opens, it creates a new file for screen bitmap, keyboard and mouse and then binds them to /dev of each terminal, since every window/terminal is actually a new namespace.
DWL inherently can't be an equivalent of DWM due to the way you configure it, but it seems like a good replacement. However I did address this in the video
Wayland doesn't support virtual displays either (:DISPLAY) which is atrocious when you want to use something like xpra as your setup, to connect to that locally and remotely so your desktop state is the same. Like tmux. Or without xpra like Google remote desktop that runs in a virtual display session. No, VNC is unfeasible and irrelevant. No, running an emulated VM is infeasible either. And xfce, with the window compositing setting disabled.
@@BrodieRobertson well they should, if they want 'writing a wayland window manager' to be simpler xD Mir speaks wayland and already implements most of what they otherwise need to implement themselves xD
yes yes yet again another same. lets forget X and start fresh and lets just do one and one linux OS no distros. torward say what is DE for linux OS mayby irs fedora xD
I hope they make awesome or a fork for wayland someday as it becomes the standard, i really love it and i'd hate to need to migrate to something else, at least there are some tiling window compositors, i'd really hate to be stuck with gnome.
I'll be honest, never understood why anyone uses those simple windows managers, besides someone with only a craptop. It just seems less intuitive and looks ass.
When I first heard of Wayland, (too) many years, ago, I was happy and thought somethign like 'finally the days of the cluttered and annoying X are counted!' And now? As an XFCE user Wayland still is an early access thing with questionable future to me. I won't ever use a terrible non thought through wannabe desktop, like the modern Gnome or KDE .. There are reasons why classic desktops are what they are after decades of improvement. Ditching all these decades of experience without any reasonable concept ('looking nice' is no productivity related concept and also just subjective) or even a plan, is just crazy! And as long as XFCE isn't on Wayland, there's no Wayland .. But sadly it seems they are continuing the wrong route here .. the route of 'relentlessly make it look it as simple as possible and throw away all the advantages an PC can have compared to casual devices like smartphones and tablets'. But why should anyone use an PC if it offers the same grade of primitive experience? PCs are optimal for sophisticated people doing sophisticated things in the most efficient way. PCs don't make any sense as oversized, overweight, overly power hungry dumbed down to smartphone level as 'kiosk mode' devices.. and that's what Gnome and KDE are pointing at .. as well as most other UIs of course, like Windoze and Crapple .. I don't believe in Wayland anymore . It's the thing that never will be done, and even if it would be done, it most probably won't suffice my needs. If they really decide to ditch X and if XFCE doesn't make it to wayland, I am done with PCs. They aren't even halfway as fun, as they used to be in the 80s anyway ;)
Meh, this is just more FUD about Wayland being the only way forward. Anyone who looks at the work required to make a Wayland compositor and says "phew, that's a lot!" clearly has no conception of how large and unwieldy X11 is. The tradeoff for people being able to write relatively small and nimble WMs was the backend being a gigantic disgusting hairball with workarounds built on workarounds. Just like building a web browser is a hideously complex project, so is developing the entire user-facing software stack, and that's what you're taking on when you write a compositor. wlroots is a great library that abstracts away a lot of the technical stuff, and as the community matures and more people move to Wayland instead of clinging to their X environments for minor things like badly-designed apps not having any way to listen to global hotkeys, these tools will only become more robust and it will get easier for random niche compositors to get made.
@@BrodieRobertson because you titled the video "Wayland is Ending the simple Linux window manager"? Even if it's not the actual thrust of the video (you did mention a couple smaller projects, though you missed several such as river and hyprland), at least the headline is riding on the "wayland bad" backlash train. Both reddit posts you cite are much more guilty of this than your video, especially the one from the developer who was trying to use Weston as a starting point, something even the official Wayland documentation doesn't recommend.
@@Aldrenean I did mention river what are you talking about? Weston is the reference implementation of Wayland, that's literally what it exists for. Did you watch to the end of the video when I discussed the scene api?
As some kind redditor pointed out to me one day. These GNU/Linux projects aren't consumer products. They have 0 incentize to do things the way you desire.
@@BrodieRobertson Seems like the Comment I made with the reddit link didn't get through, sigh. It is very likely that the xdg config is bricked. This is because unlike sway, hyprland does not automatically import the user environment variables. You sadly have to explicitly do it yourself. Otherwise applications like firefox etc are slow to start and pipewire capture (ofc) impossible. a file at /home/yourusername/.config/environment.d/envvars.conf with the following content: WAYLAND_DISPLAY=wayland-1 XDG_CURRENT_DESKTOP=wlr import these variables to hyprland inside your hyprland config; (first lines preferably) #fix the freaking portal exec-once=systemctl --user import-environment exec-once=dbus-update-activation-environment --all As you can see, I also got frustrated with that :P If this isn't the issue then I could help via matrix/discord should you still be interested to make a video about it :)
That's not inherently a bad thing, Xorg worked as the one standard everyone built for, there are other X11 implementations but no one cares if there tool is suboptimal on those
One thing I completely forgot to include is qtile, this is a window manager that actually did build a Wayland compositor alongside the regular Xorg version. As I said that it can absolutely be done but many project aren't going to take on that task.
My take on it is that if a project was started with the goal of supporting both, it'd be rather easy over time for them to achieve that goal. But most projects are started with the idea of only targeting one, so they don't bother to understand the other and as a result the implementation and end users suffer. Understanding the differences is part of what makes us and the software better. The same method of development should be applied everywhere, and if it were, Linux would be an overnight success because game developers would be better at targeting it.
I've been trying qtile just this week, and although the Wayland version works, it doesn't feel as stable as the Xorg version. For instance, it logs errors about elements or functions not being available, even though I'm using the default config. And then there are glitches like not being able to use menus in applications, or sudden dbus errors shutting down the entire WM.
So this seems to prove the point implementing Wayland is hard, if not for the initial implementation, then for ironing out the bugs.
Seems like something Redhat should tackle. They handled pipewire really well and it most certaintly helps having a large structured company with plenty of well payed workers.
Fedora Workstation promoted Gnome on their distro, which has the best Wayland support from all DEs, not sure they would be very interested in this.
I’m not sure how such a project would fit into RedHats business model. ROI for example. You’re probably right, though, this might require the involvement of a larger scale development team working full-time.
@@luckyowl10 yea, pipewire had a more significant incentive for them. Wayland is much of a concern if gnome and KDE handle their end of it.
@@donaldmickunas8552 maybe it can be like glorious eggrole and a single dev or a few devs work on a simple compositor, but yea I can see them not bothering as a company.
Redhat is taking Wayland with Gnome there is theirs supports
Well, wlroots is meant for this exact thing. It is a modular Wayland compositor meant for building custom compositors. So that is what Wayland window managers should be using as their core. And work on improving together if they think it's insufficient. Great to see that Sway is creating an easier API for it. I bet this will lead to a lot of new Wayland window managers.
Anyway Brodie. A year ago I never liked your videos and thought you were waffling without much info back then. But nowadays you are by far the best Linux creator on all of TH-cam. You are very knowledgeable, you have deep understanding of both the user and developer sides of issues, you always avoid FUD and drama, and you have great presentation skills. I don't know how you did it but you are now the only person whose videos I always watch. Super great job, man!
Regarding your second point, yes, I have to commend Brodie for finding, researching and presenting good, relevant topics. Actual good journalism work over here.
luke smith is my favorite content creator
You can make a full windows manager for x11 in 20 lines of code (with no dependencies besides xlib). Even with wlroots, it takes around 2000 lines of code to get feature parity with those 20 lines of code.
luke smith is my favourite crypto bro
@@BrodieRobertson Luke Smith is my favorite "conspiracy theorist who will definitely end up living in a bunker unironically one day". 😉👌
This reminds me the situation with Vulkan vs OpenGL. Compared to OpenGL, Vulkan requires much more boiler plate code and a lot of work just to draw a triangle, but once you do the legwork, it gives you much more control and performance out of your hardware.
I think your point is well-made, Brodie. I've been looking at porting fvwm to Wayland (which is laughable -- it's going to be a rewrite at best) -- and because of how disjoint everything is, in that compositors are now their own server as well, the mapping of features from X11 window managers to Wayland compositors, is either very difficult, or non-existent. For example, in fvwm, the window borders and title will often look similar to MWM, which has a 3D-effect. This is something a Wayland compositor would have to do via SSDs. However, to do that, third-party libraries are required to now draw and style the rectangle. Unfortunately, this boils down to either using libcairo, or using my own library (unwritten). libcairo does not support the requirements at all, so themeing is a no-go in terms of translating key features from X11 -> Wayland.
This is fundamentally due to the fact that X11 was responsible for drawing all graphics, so there was a great deal of flexibility there -- but until third-party libraries such as libcairo offer the same functionality, this is going to be very tough for certain WMs to transition to Wayland, whilst keeping their core feature sets -- these are, after all, why users continue to choose these niche WMs in the first place.
As for wlroots -- it's helpful when removing the boilerplate code, but even that has certain subjective ideas which are hard-coded.
I think wlroots might become new xorg in the wayland world, cause lots of wayland compositors are based on them.
That's what I hope to see
I think you'll see a few major compositor libraries and then several compositors which implement their own libraries. I don't think you'll see a single defacto library
@@monkev1199 after leaving the reference standard Weston behind we did multiple libraries but over the years we've been converging on 3 core choices GNOME, KDE, and of course wlroots
As long as GNOME decides to actually rethink its extensions. Because right now mutter and wlroots apparently are causing fragmentation. Just look at CSD vs SSD for example.
and the one being used by cosmic DE.
For better or for worse, Wayland is forcing a process of standardization through association that takes more effort and coordination than just implementing an Xorg compositor, but that at the same time gives you a lot of freedom.
So in the near future we will have GNOME/Mutter, KDE/Kwin and WM/Wlroots. If you wanna make a new project instead of reinventing the wheel, pick an option.
in the long term, I feel like that's best, making the software fragmentation smaller helps make the code quality higher and have less bugs.
@@luckyowl10 It will actually just have the opposite effect, BECAUSE lots of people will not be happy with it.
At the same time GNOME, KDE and wlroots don't support the same extensions for the same task so that's causing fragmentation. Or is GNOME causing all this mess?
That was actually an interestring topic. Yes, you have to do much more stuff to create a wayland compositor than a X11 window manager. But because of an intense wlroots development, this complexity was regressing recently. At the begining of this year I've forked a dwl to create a compositor which looks more like a dwm. And it was horrifically resource-hungry, because of a simple-but-clear render logic. Not long ago I've updated my compositor with a new wlroots version, with a scene-based render, which actullly fixed a problem with a resource consumption, while made the code more clear. So, while wlroots progressing, I think it will move us closer to the situation, when developing a compositor will be as easy as a developing a window manager.
actually I feel it's the opposite. The window manager scene has been dead for at least 5 years. Gone are the days when every couple of days a new window manager appeared. Now with wayland and wlroots there are quite a lot of small little compositors that it actually feels a bit like 2010 again. So yeah, it might be harder to create a wayland compositor, but projects are actually happening which makes the linux landscape feel a lot more alive again.
Most people are looking at already existing manager instead of new ones. Aka they expect the devs of existing managers to create essentially a second manager, which is ofc something they will not want to do. However, other people want to create their own project which is happening rn in quite a large amount.
I think people are making new window managers, because there aren't as many good ones yet. For xorg there are tons of great window managers, there is no point in making your own window manager in xorg, other than for programming practice. For wayland only a couple good ones exist, there are certainly still people not perfectly satisfied with any one of them.
Qtile works on Wayland, they managed to port it quite fast. Awesome works on Wayland too, right? i3 works for sure. I think that covers most people. Sorry Ratpoison enjoyers, your WM has been dead and irrelevant for the past decade
@@spicynoodle7419 QTile has a Wayland Project. Awesome most certainly does not work on Wayland and attempts to port it are long abandoned. i3 also does not work on wayland but there is a similar WM called sway which is built for Wayland.
Things don't just "work in wayland," they have to be rebuilt from the ground up, and the ratpoison is tasty and helps me stay thin.
@@ribethings every 30 years. Also yes.
This is the exact reason I'm still on X in my computer
I, for one want wlroots and Wayland to succeed. Wayland is still relatively young, and I wholeheartedly expect it to take off at some point. it's a whole lot better supported than it was when it first came out. Especially on my hidpi machines, I use it over xorg any day. We may lose some old window managers, but there will (hopefully) be a viable replacement for it, just like sway did with i3. I also like the really cool concepts that some wlroots managers have come out with, like newm for example
LOL, I had a conversation on Twitter with probonopd and had no clue who he was until I saw them mentioned here.
He recently had arguments with OBS studio developers about appimage.
Coming from gnome and switched to hyprland as my first tiling window manager. Nothing feels better handpicking and cooking your own environment tailored to your workflow.
Great video with great explanation of the issues, as it also fits into the idea what I got about Wayland from other information sources:
Basically the whole point behind Wayland was actually to make it kind of as small and simple as possible, to remove any extra functionality from it (compared to the monstrous X) that the compositors themselves already do.
I can totally see how for the smaller compositors and desktop environments that exactly can be a bigger issue. Because they where performing the same job of simplicity and minimalism as well.
Functionality needs to come from somewhere. Having a helping library (like wlroots) can help indeed. But there's one caveat: the chance that this eventually might be going to be bloated again, because, once again, it's complex functionality, but just on on another place (in the library). It needs to be extremely well designed from the start.
Among the "simple wm", qtile did it. On the main repo, not as a secondary project.
I havent tried wayland version, there are for sure issues, but well the most is there
I feel like Xorg and Wayland are built so differently that rewriting from almost scratch might be easier and more efficient for some projects than porting Xorg codebase and make it work
I'm embedded Linux developer. So I've done plenty of x window management and other low-level x calls. I can't imagine having to do everything that x does. Wayland seems like a nightmare.
wlroots?
ppl are working on libraries now. it will take time. old X was quite messy. it also had not many library. weston, sway, wlroots all working on and more will join them.
I'd be interested in hearing your thoughts on Cage (if you've heard of it).
I would give the current Wayland team a decade at best before their complaining about how big Wayland is after every Wayland render has implemented 2/3rds of X11.
@@MrjinZin0902 old X was very simple as well. Making an entire window manager with X has always been around 20 lines of code.
Sometimes I feel like most of those small WMs could be implemented as a river WMs instead of a new compositors, obviously if you have a WM that does something unique it may be not enough.
And even tho I have my own compositor, I really enjoy the possibility of creating a WM in an hour or two in river, it allows you to experiment with ideas really quickly.
I had heard that wayland was trying to be minimal but had assumed it would have registration points for the various parts and prebuild libraries for each registration so there would be a "Default" wayland setup and then you can replace each library to fit your needs but hot damn this explains why wayland support is so atrocious
A Wayland JWM would be interesting.
When XFCE makes the switch and is stable, then I will switch.
Until then I let you tell me about how it keeps getting better.
It does seem like Wayland needs *something* for devs to latch on to. wlroots is that thing in a lot of ways, but from what I'm hearing here it's very low level and a lot of work.
Maybe an "easy mode" API in wlroots is the answer, maybe its Wayfire, or maybe something like DFL libraries the Desq project started if those happen to get any traction.
The easiest way to understand what the problem is with Wayland is to dispel a common misconception. There is no Wayland display server, it's not really a replacement for Xorg at all. Wayland is nothing but a protocol. The reality is, if your system is running "Wayland," the Wayland team deserves very little of the credit. All of the heavy lifting is being done by the Linux kernel's display drivers on the low-level side, and whoever wrote the compositor on the other. Wayland only standardizes a protocol compositors and drivers should use to talk to display devices. That is pretty much all it does, and it doesn't even do a great job of that... there are tons of vendor-specific extensions. They just decided to call the new thing Wayland because people would have been mad if they had just straight-up told people they were taking away the X server and requiring the kernel and compositor to step up and fill the void because they were sick of the responsibility, but that's pretty much what the developers of Wayland decided to do. To get out of the way and tell everyone else relying on them to figure it out for themselves, providing little more than a vague protocol that is a pale shadow of X11 as guidance or assistance. Linux was always GNOME-centric, but I feel that problem will get even worse now, because not everyone has the skill to write a good compositor, and GNOME will write their compositor only for their own needs, and there won't be something more general that any Window Manager or GUI toolkit can tap into. They basically decided that if you don't have the skill to write your own compositor on par with that of the major DEs, then well, it sucks to be you, but you don't get a seat at the table anymore and choice/freedom has to take a backseat to security, tighter integration, and speed, which all also require more centralization.
What a load of BS, misinformation and FUD. I award you no points.
@@MyAmazingUsername very eloquent and comprehensive counterargument
Well, which of the points is "misinformation" to you? To my eye the following statements are true: Wayland is just a protocol, doesn't provide any APIs or libraries. If you want to write Wayland window manager you have to implement the protocol, which is the equivalent of writing a WM and an X11 implementation (basically an Xorg fork). Doing that requires a big team of professionals and realistically only big organizations can pull it off (GNOME, KDE). Sure, if you a small project you can use wlroots, but we have to remember, that it's not part of wayland standard (just another implementation, not an official library), and we have to be greatful for its existence, because that's the only one realistically possible way to bring WM's to wayland, but it can't address all of the shortcomings of the standard. In my humble opinion, as a soon to be future standard wayland is a dumpster fire. And if nothing changes, personally, I don't think I will switch from X11, despite its shortcomings, it's actually "workable" standard and Xorg is a solid implementation.
@@LA-MJ I already gave it the amount of time it deserved. If someone is willing to engage in that much vitriolic FUD, I doubt that their minds can be changed. I get it; some people hate Wayland. That is a very cool and unique opinion to have. 😂👌
@@MyAmazingUsername You wrote two comments essentially saying "Nuh uh". You're a master of persuasion.
sounds like a skill issue
ok but really ty for bringing this up it’s a really interesting point
I will mourn the passing of OpenBox
Partly why I stick with Xorg is that it's much easier to build upon. There is much more to learn if you want to make a wayland environment.
how did u archieveed this keyboard layout appet? i use sxhkd, but how s even possible to have itas a gui? i guess it s from kde
Projects like wlroots are the solution for this. A plugable compositor for wayland based operative systems, where the devs can just enable or extend the subset of features they want. This approach have some great adventages, for example, there are features which are not easy at all to implement (vulkan support, color management, 10 bits, HDR, multi-monitor extended window...). Imagine if every OS had to implement this by themselves. They don't; They just use wlroots.
I really am just watching a recap of GitHub drama. Golly damn.
I still dont quite understand how wayland fits in with a compositor and with a DE. Where can I read up about it?
I guess you could describe the change as some vertical integration between the window manager and display server which provides more flexibility by virtue of accessing both systems in one process
im planing to try make window manager someday but , it seems like its a bit of a big project
it will take a time. I don't think existing wm will port to wayland but new wm will be created by many other people. a lot of library will have to be made before that. weston project also is making libraries. with enough of library, a lot ppl will work on new wm.
This Video:
🛫
😶
It seems there is a trending on complicating APIs.
Wayland works really well on a new machine I bought this year. Doesn’t work so well on my gaming rig from 2018.
3:14 i feel like i have heard the same with ipv6
If Wayland can allow me to get Windows 98 like functionality on older hardware, I would be thrilled. X is resource intensive with lots of overheard.
I am kind of confused now, as a user I thought Wayland was easier for devs to implement and maintain while I cope with the mess. Now it just seems like the mess is on both sides.
not quite true. X is mess and bloat. but it is old project. X have tons of library. wayland is pretty new project and they don't have many library just yet. that's take a time. weston and sway are developing libraries. that's good sign. wayland protocal has been pretty stable. soon we are going to see a lot of new wm. I'm pretty sure of it.
@@MrjinZin0902 I am not sure if I should be glad on that one. I want to use input-synaptic but it seems to be quite locked down on libinput, which also needs to be separately implemented by the compositor. And I hope they have plans to unify the extensions or we will end up with 3 factions with software that won't work on others.
I tested it too now, good start and somewhat simple, wierd scaling in the example config. Now most things seems good but my games was not starting.
Wayland problems are still very much a thing. One case I had just a few weeks ago was that I can not screencast with most software due to all of the changes. I get that it's necessary to fix the security issues with X but no one is interested in porting their software over to Wayland.
to be honest, it might be easier and more efficient to write from scratch as it is optimal for Wayland, than port Xorg codebase
@@luckyowl10 and who's going to do that? lol
i think the best path forward is something similar to X's situation, where people simply use wayland as the display server and literally just write seperate compositors and WMs for it
it's just that the compositor has to do so much more now
You can't really do both unless the implementation designs around a seperate wm and compositor process (which would be great for robustness). The die has been cast on the public api side and any real effort has to go on the server side.
Such a gambit of many things. Wayland has become easier to use. My desktops are xfce and kde. I love dwm and icewm. Wayland has improved in terms of setup and bugginess. Development wise we're still looking at some time before it becomes official. A lot of will sees. It seems like most old software will fade away and the new will be developed and its own thing. I think it's still very new and seems to need to develop more solutions to Wayland with the components under the hood.
sway does not let you use commercial device drivers...hopefully the open source nvidia drivers get caught up enough.0
I'm wondering if we'll see a compositor at some point which recreates some of the plugable behavior of X, such as window managers. It would likely be much easier to port a window manager from X to such a hypothetical wayland compositor than it would be to build a compositor around a window manager.
Anyone know how to do xdotool-esque window-class* matching on wayland?
Generically no, there's nothing in the Wayland API to allow but certain compositors may provide an interface
@@BrodieRobertson yeah, and this is why I do not want to switch. Quite sad and pathetic that such a trivial functionality is missing, really...
i d still want a working PAM module that i can actually operate the way it used to do before the project was discontinued. PAM was one of the best linux modules, but it has been deprecated and changed in a way that makes it impossible for a normal user to set up properly for say: USB-stick oriented login access. please anyone who got that set up properly under wayland or later ubuntu versions, show me how...
On my kde arch install the custom shortcuts aren't even available on the wayland session. It took me hours of research before I realized that I was in a wayland session. When I switched to X the custom shortcut menu was present. Also my presets in "easyeffects" didn't work in the wayland session. but do work on X.
isn't easyeffects managed by wireplumber/pipewire not wayland?
I'm very annoyed by the way X11 has been treated. X11 is a protocol, and while it has some issues because it puts the dividing line between client and server in not quite the right place, I see no vision for what to do instead that has anywhere near the flexibility.
I discovered a long time ago that GNOME/Gtk basically completely tossed all the features of the X11 protocol in favor of just capturing every possible event and doing all of their own drawing. Of course X11 is going to work terribly when you do that.
*sigh*
I'm still confused on why no one is making something like X12... Or something like that and streamlining X11 with bugfixes, removal of old code (that in most cases nowadays is considered bloat) and mostly keeping it indeed usable for WM makers...
Wayland is the spiritual successor to X11
@@BrodieRobertson spiritual, but I mean like the same codebase but adding things to it and keeping it as a display server and not moving the compositior to a different program, as in the DE itself...
If someone is able to write efficient code that can be moved into X itself then you can call upon X features (IDK how it works but this is how I think it does) and activate "X12 extensions, functions or services" that have been added or replaced current X11 functions. (that wouldn't be me since 1 I can't code in C, 2 python and JS I can kinda code in but I totally suck at it and 3 programming isn't my interest.)
@@imtiredtoday Check out my history of X video for the full story but prior versions of X were traditionally not compatible with applications from the earlier versions
There are notes for a proposed “X12”, which you will find on the xorg site somewhere. That’s been knocking around for years ... decades.
The trouble is, X is full of legacy baggage (like graphics rendering calls) that needs to be dumped. At one time it even provided a font server, but luckily they were able to get rid of that. Once you remove this stuff, you realize the basic architecture of X, which allowed for having such things in the first place, is over-complicated.
ive tried to take up the task of continuing way-cooler, one of the attempts at getting awesomewm to wayland, and basically given up after being advised that its a futile task
stuff like this is why it's going to be a bit until I port over to wayland
I've tried everything with excitement... But I always end up back with my vanilla dwm... It's everything I need and want... Nothing more, nothing less...
There's still a dream of X12
With the rate at which Wayland is going, you'll probably see an X13 before too long.
According to the Xorg Foundation, Wayland is just X12 under a different name, and like Wayland, none of the previous X protocols were backwards compatible.
Brodie is the most relevant Linux youtuber
I think we will just see different forms of modularization than xserver model. It will be different not bigger.
Ah yes... The fruits of the "we define only a protocol" fallacy. Same thing as with X11. Initially it was only supposed to be a protocol definition. This let to initial waste of efforts by multiple vendors to provide different implementations. Later everyone got so annoyed by minute differences between the different version, that more and more applications just went over to windows. After some time all the different vendor specific implementations of X11 got basically abandoned. So for a lack of alternative Xorg remained. It mainly remained because there wasn't anything else around. However it was still a rotting away project. The same future is awaiting wayland. With one important difference maybe: Vendors don't even care about it initially.
Old window managers may die out, but can new snowflake window managers not use sway as a base instead of building wayland from the ground up.
I'm working on an awesome like Wayland compositor but I don't expect it to be decent untill a good few months or years
I loved E17 and Enlightenment. I used them way way way back when they were new and shiny and alpha. WOOF. Sexy accelerated eye candy of the time and I miss them. Someone has picked up Enlightenment but want to get paid to work on it. When I'm rich I will feed anyone working on enlightenment.
Wayland is just another try to copy what Plan 9 from Bell Labs did decades ago.
Hint: what is missing is not a feature of the Wayland, is a feature of the OS (private namespaces (mount namespaces in linux) being actually used and useful). Plan 9 solved the capture problem by creating "device" file (not exactly that, there's nothing like "device file" in Plan 9, files has a whole different meaning) for the image, maybe the solution is to create these char devices for wayland and use UNIX permissions to tackle the security.
What kind of GUI architecture does Plan 9 support?
@@lawrencedoliveiro9104 Its only Rio. For each window rio opens, it creates a new file for screen bitmap, keyboard and mouse and then binds them to /dev of each terminal, since every window/terminal is actually a new namespace.
the thing that makes me sad is that sway doesn't have nvidia support.
why need to replace "X" just focus on X and make X better.
The money and development has moved on from X
3:15 maybe he's using valve time?
This is my comment. There are many others like it, but this one is mine.
My comment is my best friend. It is my life. I am nothing without my comment.
This comment supports me. I trust my comment.
If every wayland compositor needs the same boilerplate code why not just add it to wayland directly via merge request
This really isnt true though if you're using wlroots. See dwl, a wayland equivalent of dwm
DWL inherently can't be an equivalent of DWM due to the way you configure it, but it seems like a good replacement. However I did address this in the video
Wayland doesn't support virtual displays either (:DISPLAY) which is atrocious when you want to use something like xpra as your setup, to connect to that locally and remotely so your desktop state is the same. Like tmux. Or without xpra like Google remote desktop that runs in a virtual display session.
No, VNC is unfeasible and irrelevant. No, running an emulated VM is infeasible either.
And xfce, with the window compositing setting disabled.
I only use qtile, and support is ok, but can tell homie getting a little burned out on the wayland work.
Qtile already works on Wayland, thanks to wlroots. So if I ever switch to Wayland, at least this is not a problem anymore. 🙂
Wayland isn't killing X-only software. X-only software is killing Wayland.
Why every shiny Linux component that claims to be "the future" make open-source developement harder and harder ?
I'm sad not wanting to leave the Wayland bandwagon knowing my beloved xmonad wil never be ported; even if it's just a wlroots skin
They thought it was good idea substitute working software with a protocol. lol.
very interesting video
Ok remind me to worry about this in 2038 when Wayland becomes the standard
Pffft, even by then it won't be haha
On the background: Which Way is the Land?
Me: Currently, it's Way Too Much
Untill they embrace mir i suppose
Mir is for wayland what xorg was for uhh x11
No one is embracing mir lol
@@BrodieRobertson well they should, if they want 'writing a wayland window manager' to be simpler xD
Mir speaks wayland and already implements most of what they otherwise need to implement themselves xD
qtile is on wayland
yes yes yet again another same. lets forget X and start fresh and lets just do one and one linux OS no distros. torward say what is DE for linux OS mayby irs fedora xD
I hope they make awesome or a fork for wayland someday as it becomes the standard, i really love it and i'd hate to need to migrate to something else, at least there are some tiling window compositors, i'd really hate to be stuck with gnome.
It probably won't be a "Standard" the way things are going, you'll be waiting another 15 years
> but they fell bythe *way*side
🤔
And I love that.
You might love Hypr Wayland window manager
I'll be honest, never understood why anyone uses those simple windows managers, besides someone with only a craptop. It just seems less intuitive and looks ass.
The fun of building a system and I like the workflow
looking purdy isn't productive
Much lower overhead. Also simplicity.
When I first heard of Wayland, (too) many years, ago, I was happy and thought somethign like 'finally the days of the cluttered and annoying X are counted!'
And now?
As an XFCE user Wayland still is an early access thing with questionable future to me.
I won't ever use a terrible non thought through wannabe desktop, like the modern Gnome or KDE .. There are reasons why classic desktops are what they are after decades of improvement. Ditching all these decades of experience without any reasonable concept ('looking nice' is no productivity related concept and also just subjective) or even a plan, is just crazy! And as long as XFCE isn't on Wayland, there's no Wayland ..
But sadly it seems they are continuing the wrong route here .. the route of 'relentlessly make it look it as simple as possible and throw away all the advantages an PC can have compared to casual devices like smartphones and tablets'.
But why should anyone use an PC if it offers the same grade of primitive experience? PCs are optimal for sophisticated people doing sophisticated things in the most efficient way. PCs don't make any sense as oversized, overweight, overly power hungry dumbed down to smartphone level as 'kiosk mode' devices.. and that's what Gnome and KDE are pointing at .. as well as most other UIs of course, like Windoze and Crapple ..
I don't believe in Wayland anymore . It's the thing that never will be done, and even if it would be done, it most probably won't suffice my needs. If they really decide to ditch X and if XFCE doesn't make it to wayland, I am done with PCs. They aren't even halfway as fun, as they used to be in the 80s anyway ;)
Meh, this is just more FUD about Wayland being the only way forward. Anyone who looks at the work required to make a Wayland compositor and says "phew, that's a lot!" clearly has no conception of how large and unwieldy X11 is. The tradeoff for people being able to write relatively small and nimble WMs was the backend being a gigantic disgusting hairball with workarounds built on workarounds.
Just like building a web browser is a hideously complex project, so is developing the entire user-facing software stack, and that's what you're taking on when you write a compositor. wlroots is a great library that abstracts away a lot of the technical stuff, and as the community matures and more people move to Wayland instead of clinging to their X environments for minor things like badly-designed apps not having any way to listen to global hotkeys, these tools will only become more robust and it will get easier for random niche compositors to get made.
How did you come to conclusion that it's FUD when the video ends with me discussing a change that's going to help to bring things forward?
@@BrodieRobertson because you titled the video "Wayland is Ending the simple Linux window manager"? Even if it's not the actual thrust of the video (you did mention a couple smaller projects, though you missed several such as river and hyprland), at least the headline is riding on the "wayland bad" backlash train. Both reddit posts you cite are much more guilty of this than your video, especially the one from the developer who was trying to use Weston as a starting point, something even the official Wayland documentation doesn't recommend.
@@Aldrenean I did mention river what are you talking about?
Weston is the reference implementation of Wayland, that's literally what it exists for.
Did you watch to the end of the video when I discussed the scene api?
just use wlroots lol
X does have issues on newer systems. It crashed constantly while wayland is perfectly stable on my system.
X hasn't been updated for some time because everyone ditched it to work on Wayland, so now you have two broken display stacks, yaaaaaaay.
As some kind redditor pointed out to me one day. These GNU/Linux projects aren't consumer products. They have 0 incentize to do things the way you desire.
Even though I use Linux on a daily basis, but Linux is the worst desktop OS!
False: the simple windows manager is ending Wayland.
Are they?
I am going to say it until you try it, hyprland.
Capturing it is the problem
@@BrodieRobertson wlrobs?
@@BrodieRobertson capturing it? Are you talking about pipewire here, or what am I missing? Genuinely confused :D
@@DashieTM I've had issues opening OBS on hyprland
@@BrodieRobertson Seems like the Comment I made with the reddit link didn't get through, sigh.
It is very likely that the xdg config is bricked. This is because unlike sway, hyprland does not automatically import the user environment variables. You sadly have to explicitly do it yourself. Otherwise applications like firefox etc are slow to start and pipewire capture (ofc) impossible.
a file at /home/yourusername/.config/environment.d/envvars.conf
with the following content:
WAYLAND_DISPLAY=wayland-1
XDG_CURRENT_DESKTOP=wlr
import these variables to hyprland inside your hyprland config; (first lines preferably)
#fix the freaking portal
exec-once=systemctl --user import-environment
exec-once=dbus-update-activation-environment --all
As you can see, I also got frustrated with that :P
If this isn't the issue then I could help via matrix/discord should you still be interested to make a video about it :)
It's pretty bad since it forces centralization instead of modularity
That's not inherently a bad thing, Xorg worked as the one standard everyone built for, there are other X11 implementations but no one cares if there tool is suboptimal on those
@@BrodieRobertson that's always a bad thing for this OS lol
Brod(i)e
Make video (debunking) distro(tube)
why (are) yo(u) talking like (this)
why are (you) questioning (the) guy called (Xi) (Jinping)
@@BrodieRobertson good (question)