111–120 of 335 posts
Earlier quoted context omitted.
I have essential workflows using x2x, xev, and xdotool. Apparently this kind of stuff is contrary to Wayland's security model, so I'm stuck on Xorg, and I'm ok with that.
Out of curiosity, what are these workflows?
I can’t find a low-effort, high-portability, low-menory way to do it with Wayland.
Local and also in CI pipelines.
A rather big problem is that Wayland is just a protocol, not an implementation. There are many competing implementations, like Gnome, KDE and wlroots. The problems you have with one of them might not appear in another. The reference compositor, Weston, is not really usable as a daily driver. So while with Xorg you have a solid base, and desktops are implemented on top of that, with Wayland the each desktop is reinven…
Earlier quoted context omitted.
Everyone’s so excited about the wave if windows users coming to Linux. Those people already have monitors. I switched in 2018 and was surprised I couldn’t use fractional scaling on one monitor like I’d been doing for years on windows.
Not to mention that fractional scaling is practically required in order to use the majority of higher DPI monitors on the market today. Manufacturers have settled on 4K at 27" or 32" as the new standard, which lends itself to running at around 150% scale, so to avoid fractional scaling you either need to give up on high DPI or pay at least twice as much for a niche 5K monitor which only does 60hz.
Save money on the monitor, save money on the gpu (because it's pushing fewer pixels, you don't need as much oomph), save frustration with software.
Earlier quoted context omitted.
You are conflating Window Manager with Task Switcher programs.
No, I'm not. Explore and Dock are responsible for more than just that.
Note to people on this thread: the impression the discussions give is that Linux isn't ready for prime time desktop use. I thought Wayland was the latest and greatest, but folks here report issues and even refuse to ever use it. Windows and Mac Os, for all their faults, are unquestionably ready to use in 2026. If you are a Linux on desktop advocate, read the comments and see why so many are still hesitating.
For me, Wayland seems to work OK right now, but only since the very latest Ubuntu release. I'm hoping at this point we can stop switching to exciting new audio / graphics / init systems for a while, but I might be naive.
Edit: I guess replacing coreutils is Ubuntu's latest effort to keep things spicy, but I haven't seen any issues with that yet.
Edit2: I just had the dispiriting thought that it's about twenty years since I first used Ubuntu. At that point it all seemed tantalizingly close to being "ready for primetime". You often had to edit config files to get stuff working, and there were frustrating deficits in the application space, but the "desktop" felt fine, with X11, Alsa, SysV etc. Two decades on we're on the cusp of having a reliable graphics stack.
I mean, it works alot better than it did before, still i wouldn't recommend it for someone who isn't ready to tinker in order to make stuff work.
The point why i mention this is, while most normal desktop/coding stuff works okay with wayland, as soon i try any gaming its just a sh*show. From stuff that doesn't even start (but works when i run on x) to heavyly increased performance demands from games that work a lot smoother on x.
While i have no personal relation to any of both, and i couldn't technically care less which of them to use - if you are into gaming, at least in my experience, x is rn still the more stable solution.
Earlier quoted context omitted.
I use it as my daily driver. I used Sway for a very long time, tried Hyprland for a bit and am now running niri as my daily driver. Sway and niri are wlroots based, Hyprland at some point rolled its own because they didn't want to wait for wlroots protocol extensions. Sometimes I have to switch to Gnome to do screen sharing. 2026 and you will still run into plenty of issues with random behaviour, especially if you ru…
niri is based on smithay which is also used by COSMIC.
Earlier quoted context omitted.
I mean proprietary API in the sense that the API is solely owned and developed by Mesa. It is not a standardized API, but a custom one specific to their project. Even today if you use the API your program has to link to Mesa's libgbm.so as opposed to linking to a library provided by the graphics driver like libEGL.so.
OK, leaving aside the fact that "proprietary" has a very well defined meaning in this context and using it makes your comment very charged, you're basically telling us that Nvidia was not willing to implement an API for their drivers, but tried to push for one designed by themselves (you're calling it "vendor neutral", but since Mesa is not an actual GPU vendor it's most likely another subtle mistake on your part tha…
Yes, it does and it is different the the well defined meaning when talking in regards to the software itself. OpenGL is an open API, but the source code for an implementation isn't necessarily open.
>Nvidia was not willing to implement an API for their drivers
They couldn't because this API is a part of Mesa itself. As I mentioned programs link to a Mesa library directly.
>since Mesa is not an actual GPU vendor
They are a driver vendor.
>the other vendors (Intel and AMD at this point), which have already implemented GBM
Support was added to Mesa itself and not to the driver's by those companies. The proprietary, now deprecated, AMD kernel module still doesn't support GBM.
>should switch too in the name of this
I think it is beneficial for standards to be implemented by multiple vendors, so I think they should implement it at least.
>How can you call all of that a mischaracterization?
What people think as Nvidia needing to implement an API is actually an ask for Nvidia to make a Mesa API work.
From my perception essentially the ask was that Nvidia needed to open source the kernel driver like AMD did and then eventually a nvidia gbm backend would be built into Mesa for it. For obvious reasons this was never going to happen. The fact that no agreeable solution was figured out in about a decade, and then Nvidia has to code up that solution for the Mesa project is a failure on Mesa's end. A lot of user pain happened due due to them not willing to work together with proprietary software and focusing solely on supporting open source drivers.
Earlier quoted context omitted.
That's easy to say in hindsight. It is only with the specific failures of Wayland that we see which lessons it could have learned from X11.
No, the lesson of “separate display server from window manager” was very clear when Wayland was started. People have been discussing this over the years ever since. (See also “client-side decorations” for another part of this issue that was heavily discussed.)