X.Org Server 21.1 Will Aim To Release In The Coming Weeks

[leipero]

There has been years since "Wayland is ready" statement. All the issues wayland had back then are still present to this day. How can anyone expect to "transition" towards wayland if that is the case? I would be first to jump in TBH, and I don't have many issues with it to be frank, my main issues can be summed into two simple points:
1. Input lag is horrid and unacceprable.
2. The way graphical environment is handled seems very wrong, with input stutters (mouse for example) and so on.

It's really those two things that developers do not seem to have a solution for. That fact alone suggest to me that there's something very wrongly done on the implementation side of it at the very least, otherwise it would be solved easilly.

For Birdie thing, I don't think he's trolling, because the definition of trolling is saying things you don't believe in to get a reaction from others, or create chain reaction targeting 3rd person(s). IMO, he's not doing that, he actually believes what he says, hence why he's not trolling. On some points, excluding emotional response, I have to agree with him.

[Charlie68]

Its more complicated than this. Reality here we have had more DE on Linux than we have had personal to support properly. The wayland change has brought this lack of resources to head.

https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/

Yes the lack of resources for items like XFCE are leading to some horrible things. Like XFCE in fact needing more memory than KDE. Why KDE has been able to fix up their code base and move to more modern interfaces that result in using less memory running the desktop even under X11.

There are quite a few new wayland compositors that have no legacy baggage that have appeared. The smaller ones also have the question will they have enough developers.

Also this is not exactly a trivial update. As Xwayland will go forwards as it own tree under Redhat/Suse development and Bare metal X.org Server will go forwards as it own tree. This now means Xwayland and bare metal x.org can have different X11 protocol support. Worst case incompatible.

I agree, it is more complicated than that, but we try to make a synthesis.
I brought the Xfce example, but the other DEs don't fare better on wayland!
After that we can also discuss the need to have so many DEs, like me you wallpaper an open door, but we both know that Gnu / linux is not Windows or MacOS where the boss tells you what to use. Gnu / linux is a multitude of projects and this is its strength, but also its weakness.
All of this makes a transition like this, from Xorg to wayland, very slow.
For this reason I am convinced that Xorg will still be there for a long time, even if then most of the users will be on Wayland.

[Weasel]

https://securityintelligence.com/new...otkey-scripts/

Whoops.....
Yes, perfectly sane.

You know what else is used for attacks? Your internet connection.

Quick, remove it. Who needs internet? Not sane at all, can be used for attacks.

[Weasel]

This is not 100 percent true. A few things are wrong. AT-SPI2 supporting applications under Linux with the program off-screen or minimised can be controlled by AT-SPI2 even under Wayland. There are even cases under X11 where AT-SPI2 can control the off-screen application but autohotkey cannot. Attempting to control a windows that is off screen not getting any CPU time because it off screen results in nothing happening. AT-SPI2 that off screen application gets put back on the CPU que to get CPU time.

Yes off screen window not getting CPU time can happen under windows as well. So if application support assist technology you should use it. Please note this is a bug with autohotkey under windows as well. Windows does have their own AT-SPI2 equal and if used for a off screen window not getting CPU time will result in that window being put back on the cpu que. There is a right way and a wrong way to interface with off screen windows if you want 100 percent reliability and that not how autohotkey does it. So yes saying that autohotkey works with off screen windows means you must not beaware of that bug when the off screen window is suspended so autohotkeys actions are not waking it up.

AutoHotkey doesn't need any assist technology, period. I never enabled any and it always worked. Works on Wine too (but relies on X's "security flaws").

You're right about some apps stopping to render on offscreen or when minimized. That's besides the point. I said that it can, not that it works for every app. The ability to do it means Windows also allows it.

[tomas]

He's pragmatic...

Yes, pragmatism is his greatest virtue.

[Mez']

I have reported him several times. Michael in fact tells me birdie is very annoying, and has banned him twice before.
I have tried my best by deleting his messages, but I have a different timezone and often by the time I wake up the flamewar already started.

birdie hates me with a passion...

He's pragmatic and thus going against the nerd grain going on here. He can be annoying on the AMD-Intel or AMD-Nvidia topics, which I don't read much personally, but otherwise he triggers debate and some doubts to the herd of sheeps who forgot to assess their beliefs and just follow whatever trend is going on. I'm not exactly in line with him, but I appreciate him for that. Otherwise, it would be more one-track thinking and morons echoing "X is dead" without any critical mind.

[mppix]

I'd like to add, lack of emulated input, especially in a consistent way. Another synergy user, and that's somewhat of a showstopper, given it's the only competent solution I've found that's cross platform. Also for whatever reason, TeamViewer is the only remote access tool my older family members trust, and that comes back to no standard remote desktop

Also, THANK YOU to the gentleman willing to deal with the stonewall that is the xorg committee. I'll see if I can find my list of what merged with little/no rebasing and put it somewhere for him.

Actually, the transition to wayland is cleaning up a lot of the X mess. There are now standardized interfaces. Synergy just needs to add proper support. Example how it can be done:

https://github.com/htrefil/rkvm

Same with TeamViewer (same goes for Zoom, MS Teams, etc), Wayland screesharing/capture has worked for quite some time now (xdgportal), TeamViewer just need to add support for the proper interfaces. Example how it can be done:

https://feaneron.com/2021/03/30/obs-studio-on-wayland/

[xhustler]

Great work Povilas for the effort to get the community a new X release.

As for the flame wars between X and Wayland, my stance is simple - X works for all my use cases. Wayland kind of works.

Will stick with X till Wayland dots it's I's and crosses her t's.

[mppix]

Actually I can blame Wayland because the whole design of Wayland (i.e. it being only a protocol) basically forces all desktop environments to re-implement everything from scratch, where as with X.Org this was abstracted away (which makes sense because as birdie stated there is a huge amount of boilerplate/duplication here).

Uhm, no. There is now a KWin fork that uses wlroots
https://www.phoronix.com/scan.php?pa...-WLROOTS-Usage
So this solves your re-implementation issue no?

Wlroots looked like a promising solution to this problem if it wasn't for the fact that it was created by someone who prevent the software from running if you have an NVidia card in your system (even if you didn't use it for compositing and only for CUDA, i.e. you have a laptop with Intel + NVidia and you used Intel for rendering your DE) which didn't actually create promising signals for adoption by DE's that care about their users.

This is quite passive-aggressive. If you don't like the position of the wlroots maintainer regarding Nvidia, just fork the project.
I would certainly expect that the KDE community can pull that off.
KWinFT certainly did exactly that because they were not happy with KWin's Wayland strategy (or lack thereof)

Yes and as you can see its being maintained, just by someone else and the features what was released isn't limited at all. Again they can call it whatever they wan't, but its not reflecting reality.

I don't know what any of this means.

Ensuring that their distro is successful and can be used by a lot of users and not breaking stuff because you feel like it sounds like an odd thing to regret

Just because someone is not technically savvy doesn't mean they are an idiot. Calling such people idiots says more about your personality than anything else. I mean even Linus Torvalds has echoed that distro should stop breaking software for users all of the time and I doubt he is an "idiot" (it actually got so bad from his end that subsurface, a GUI application that he helped developed didn't even bother making releases/packages for Linux because it was being run by people with the same attitude you have)

So yeah, the only thing thats idiotic here is eagerly breaking functionality rather than doing things properly.

Thanks for taking this out of context! This statement was addressed at a very loud member of this forum that cannot be bothered to do 5min of googling to get the facts straight.

And you are also taking Linus Torwalds statements regarding subsurface out of context. His issue has been that libraries across distributions have vastly different versions and distributions usually don't allow you to ship your own. Going with the common denominator often means using a quite old library version, which is undesired. This can be solved by flatpak, snap, appimage etc. Btw. they have now a number of releases for Linux

https://subsurface.github.io/download/

[oiaohm]

You mean NVidia did or didn't?

Yes they did put a a solution it was not fix it. Its possible to be did and didn't at the same time. Sometimes Nvidia put forward solutions are totally wacky.

To do this stuff properly you really do need a capabilities based system, ideally in the kernel and thats what I meant by Fuschia/Android.

What do you think the capabilities system in the Linux kernel from Linux security modules hooked up to in the most complete way. Files.

Fuschia the capabilities system is hooked up to objects.

Uh I think you are completely deluding yourself if you are telling yourself that no problem/bugs exists if you use the buffer as a file is a framework. Most beings being a file is an abstraction, saying such a feature inheritly makes something secure is bullshit.

No stop. Security frameworks even in Fuschia has to have a abstraction so it can be applied. This is the everything is [x] question. You security framework has to have a [x] or the security framework cannot be applied correctly.

sel4 is a "everything is a object" its security model works on objects. Yes objects is how sel4 abstracts everything. That everything is question turns out to be very important.