IDK , Nobara is really stable. The main difference for me was that it comes with all the AV codecs you could need, and a few tweaks for gaming. Saved me a lot of time in the end.
Until my distro forces wayland on me I’ll stick with xorg+XFCE. I’ve played with sway and hyprland but I need my application choices to actually work well. (no I’m not going to list them).
As for the cube desktop in the image: We had this with compiz and learnt then that this is pointless.
There’s a big difference between Working on vs is working. They’re Working on a full port, other than that you have preliminary access that’s not intended for casual users; only developers, tinkers/enthusiast & testers.
This design document is intended for Xfce developers to begin brainstorming ideas for future development. This is a work in progress and does not imply any future implementation commitments.
No blame on the XFCE devs because they’re trying to get a lot done with few people, but XFCE just managed to transition to GTK3, I wouldn’t hold my breath for comprehensive Wayland support any time soon.
They’ve made great strides towards Wayland support, considering that the vast majority of the work is being done by 1 guy.
It’s not just a lack of devs that’s contributing to slow development time either, it’s also the fact their goal is to port every single component to native Wayland without relying on Xwayland at all; which is obviously going to take way longer than just porting the essentials and saying “fuck it, use Xwayland”.
If markdown fulfills your formatting needs, then there’s no beating it in terms of focus and simplicity. Use whatever text editor you like. My recommendation would be Kate. It supports previewing the rendered document in side by side view.
One of the specific issues from those who've worked with Wayland and is echoed here in Nate's other post that you mentioned.
Wayland has not been without its problems, it’s true. Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction.
I tend to disagree. Had say the XDG stuff been specified in protocol, implementation of handlers for some of that XDG stuff would have been required in things that honestly wouldn't have needed them. I don't think infotainment systems need a concept of copy/paste but having to write:
Is really missing the point of starting fresh, is bytes in the binary that didn't need to be there, and while my example is pretty minimal for shits and giggles IRL would have been a great way to introduce "randomness" and "breakage" for those just wanting to ignore this entire aspect.
But one of those agree to disagree. I think the level of hands off Wayland went was the correct amount. And now that we have things like wlroots even better, because if want to start there you can now start there and add what you need. XDG is XDG and if that's what you want, you can have it. But if you want your own way (because eff working nicely with GNOME and KDE, if that's your cup of tea) you've got all the rope in the world you will ever need.
I get what Nate is saying, but things like XDG are just what happened with ICCCM. And when Wayland came in super lightweight, it allowed the inevitably of XDG to have lots of room to specify. ICCCM had to contort to fit around X. I don't know, but the way I like to think about it is like unsalted butter. Yes, my potato is likely going to need salt and butter. But I like unsalted butter because then if I want a pretty light salt potato, I'm not stuck with starting from salted butter's level of salt.
I don’t think infotainment systems need a concept of copy/paste but having to write:
Having lived through the whole “phones don’t need copy and paste debate”, which fortunately got solved by now having it everywhere I’m in the camp “just stick that everywhere, just in case somebody might use it one day”
I also use Fedora Wayland but on a HP Spectre X360 from like 2013 or something, touch screen works fine and overall runs a lot better then win 10 was prior.
You will never be a real display server. You have no hardware cursors, you have no xrandr, you have no setxkbmap. You are a toy project twisted by Red Hat and GNOME into a crude mockery of X11’s perfection.
All the “validation” you get is two-faced and half-hearted. Behind your back people mock you. Your developers are disgusted and ashamed of you, your “users” laugh at your lack of features behind closed doors.
Linux users are utterly repulsed by you. Thousands of years of evolution have allowed them to sniff out defective software with incredible efficiency. Even Wayland sessions that “work” look uncanny and unnatural to a seasoned sysadmin. Your bizarre render loop is a dead giveaway. And even if you manage to get a drunk Arch user home with you, he’ll turn tail and bolt the second he gets a whiff of your high latency due to forced VSync.
You will never be happy. You wrench out a fake smile every single morning and tell yourself it’s going to be ok, but deep inside you feel the technical debt creeping up like a weed, ready to crush you under the unbearable weight.
Eventually it’ll be too much to bear - you’ll log into the GitLab instance, select the project, press Delete, and plunge it into the cold abyss. Your users will find the deletion notice, heartbroken but relieved that they no longer have to live with the unbearable shame and disappointment. They’ll remember you as the biggest failure of open source development, and every passerby for the rest of eternity will know a badly run project has failed there. Your code will decay and go to historical archives, and all that will remain of your legacy is a codebase that is unmistakably poorly written.
This is your fate. This is what you chose. There is no turning back.
I’ve been using fedora on a surface go 3 and it’s been a good experience - auto rotate works and osk mostly works. In general Gnome seems to be the best DE for touchscreens, especially if you use it in tablet mode a lot. You’re gonna at least want something up to date and probably using Wayland, so I wouldn’t go with mint.
One option is to use something like Fedora or Arch for both PCs, but use a different desktop environment (gnome on the 2-in-1, kde on the desktop).
Errrm, could they please leave some memory to other processes? KDE already takes about 1.5GB of VRAM on my RX7600 8GB just running a desktop (dual head 4k + 1440p displays). Yes, things can get swapped out to main memory, but that becomes choppy. I’d rather run single buffered, get the odd screen tear, and have the VRAM back for real work.
It says in the article that triple buffering only activates if your GPU struggles to render the desktop. That means old and weak iGPUs are getting this. For your desktop card nothing should change.
Over on Nate's other blog entry he indicates this:
The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible
And I think this is something people tend to forget. X11 as a protocol is complex and writing an implementation of it is difficult to say the least. Because of this, we've all kind of relied on Xorg's implementation of it and things like KDE and GNOME piggyback on top of that. However, nothing (outside of the pure complexity) prevented KWin (just as an example) implementing it's own X server. KWin having it's own X server would give it specific things that would better handle the things KWin specifically needed.
Good parallel is how crazy insane the HTML5 spec has become and how now pretty much only Google can write a browser for that spec (with thankfully Firefox also keeping up) and everyone is just cloning that browser and putting their specific spin to it. But if a deep enough core change happens, that's likely to find its way into all of the spins. And that was some of the issue with X. Good example here, because of the specific way X works an "OK" button (as an example) is actually implemented by your toolkit as a child window. Menus those are windows too. In fact pretty much no toolkit uses primitives anymore. It's all windows with lots and lots of text attributes. And your toolkit Qt, Gtk, WINGs, EFL, etc handle all those attributes so that events like "clicking a mouse button" work like had you clicked a button and not a window that's drawn to look like a button.
That's all because these toolkits want to do things that X won't explicitly allow them to do. Now the various DEs can just write an X server that has their concept of what a button should do, how it should look, etc... And that would work except that, say you fire up GIMP that uses Gtk and Gtk has it's idea of how that widget should look and work and boom things break with the KDE X server. That's because of the way X11 is defined. There's this middle man that always sits there dictating how things work. Clients draw to you, not to the screen in X. And that's fundamentally how X and Wayland are different.
I think people think of Wayland in the same way of X11. That there's this Xorg that exists and we'll all be using it and configuring it. And that's not wholly true. In X we have the X server and in that department we had Xorg/XFree86 (and some other minor bit players). The analog for that in Wayland (roughly, because Wayland ≠ X) is the Compositor. Of which we have Mutter, Clayland, KWin, Weston, Enlightenment, and so on. Which that's more than just one that we're used to. That's because the Wayland protocol is simple enough for these multiple implementations.
The skinny is that a Compositor needs to at the very least provide these:
wl_display - This is the protocol itself.
wl_registry - A place to register objects that come into the compositor.
wl_surface - A place for things to draw.
wl_buffer - When those things draw there should be one of these for them to pack the data into.
wl_output - Where rubber hits the road pretty much, wl_surface should display wl_buffer onto this thing.
wl_keyboard/wl_touch/etc - The things that will interact with the other things.
wl_seat - The bringing together of the above into something a human being is interacting with.
And that's about it. The specifics of how to interface with hardware and what not is mostly left to the kernel. In fact, pretty much compositors are just doing everything in EGL, that is KWin's wl_buffer (just random example here) is a eglCreatePbufferSurface with other stuff specific to what KWin needs and that's it. I would assume Mutter is pretty much the same case here. This gets a ton of the formality stuff that X11 required out of the way and allows Compositors more direct access to the underlying hardware. Which was pretty much the case for all of the Window Managers since 2010ish. All of them basically Window Manage in OpenGL because OpenGL allowed them to skip a lot of X, but of course there is GLX (that one bit where X and OpenGL cross) but that's so much better than dealing with Xlib and everything it requires that would routinely require "creative" workarounds.
This is what's great about Wayland, it allows KWin to focus on what KWin needs, mutter to focus on what mutter needs, but provides enough generic interface that Qt applications will show up on mutter just fine. Wayland goes out of its way to get out of the way. BUT that means things we've enjoyed previously aren't there, like clipboards, screen recording, etc. Because X dictated those things and for Wayland, that's outside of scope.
That’s my problem with this. It tries to be a desktop display server protocol without unifying all desktop requirements. Sure, X11 is old and have unnecessary things that aren’t relevant anymore, however, as someone who builds their own DE, (e.g.: tiling window managers) I see it as the end of this masterrace. Unless everybody moves to wlroots. Flameshot, for example, is already dealing with this, having at least 5 implementations only for linux, and only wlroots and x11 are standards.
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE. But as you said DEs can implement it simply. Let’s say wlroots will implement this but others can decide otherwise. And for those the app won’t run.
Another example, that affects my app personally, is the ability to query which monitor is the pointer at. Wayland doesn’t care having these so I doesn’t care supporting wayland. And I"m being sad about this because X is slowly fading away so new apps will not run on my desktop.
Moreover with X11 I could write my own hotkey daemon in my lanuage of choice, now I would have to fork the compositor.
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE.
The wayland way to do that is to have the application be a compositor, they made sure that nesting introduces only minimal overhead. And that ties in with the base protocol being so simple: If you only need to deal with talking to the compositor you’re running on, and to the client that you want to embed, a wayland compositor is indeed very small and lean. Much of the codebase in the big compositors deals with kms, multiple monitor support, complex windowing logic that you don’t need, etc.
Oh and just for the record that doesn’t mean that you can’t undock the terminal: Just ask the compositor you’re running on for a second window and compose it there. You can in principle even reparent (client disconnecting from one compositor and connecting to the other) but I think that’s only standardised for the crash case there’s no standard protocol to ask a client to connect to another compositor. Just need to standardise the negotiation protocol, not the mechanism.
Wayland has fixed so many head-scratching issues I would get running 6 monitors on 2 GPUs under X11. I’d often end up with missing monitors, placed in wrong spots that I’d have to rearrange every reboot until an update would come through that would fix it again for a few months, then all over again.
Since I moved to wayland, everything just works. When it doesn’t, it’s not a display server issue, it’s something physical. I just had a couple monitors fail to show up and thought “oh hell, it’s back to this, eh”. But I open the tower, seat the offending GPU better, and everything comes up like normal, and all the screens are in the right position, it just remembers.
Anyone that thinks X11 is still superior probably runs on a laptop with a single screen.
I mean I’m fully with you on the fact screen autodetect isn’t stellar on X but there’s no need to exaggerate with “2 or 3 scripts”. It’s one xrandr command.
Ive seen several devs do that, and also some of my gaming friends have 3 monitors.
I barely know anyone who only has a single display. Most people I know have one high refresh rate monitor, and one office monitor for discord and the likes.
I have 2 75hz and a 240hz. It’s been alright for me on kde and x11. Although, I do want to give this Wayland thing a shot after hearing it being brought up so many times
I actually just went through this exact situation in the last month and I switched to LMDE6 on my 2-in-1 lenovo touch screen. Auto rotation didn’t work right out the gate, but iio-sensor-proxy fixed that. In general, I’ve noticed that the touchscreen default setting for some apps (eg, firefox) treats touches as a mouse click, so rather than scrolling it would select text. But I’ve found this AskUbuntu fix worked for me. Been a good experience since then.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.