Fedora 34 To Ship With Standalone XWayland, LLVM 12 + Other Changes Approved

[Space Heater]

Mutter already got patches that moves input to separate thread so with GNOME 40 this annoying issue should be fixed or at least greatly reduced.

Unfortunately it does not fix visual stuttering:

• It does not perform KMS updates in the input thread. All KMS interaction still does happen in the main thread, so the pointer can visually stall, even though the input thread isn't missing events. Ideally, KMS management itself should be eventually taken out of the main thread. This branch sets the seed so that the MetaKmsCursorRenderer can possibly be managed there, so that KMS and the input threads could talk between themselves without interaction from the main thread.
• It does not change how wayland nor clutter receive the events. These are handled in the main thread, are still motion-compressed, etc. We might now ponder a better place to do that compression though.
• It does not let tablets use the KMS cursor renderer. It is again a possibility now, and !285 should be rethought through after this.

Source: https://gitlab.gnome.org/GNOME/mutte...03#note_892382

[timrichardson]

X is dead.

Who's X? X is dead baby, X is dead (https://www.youtube.com/watch?v=5lL1ypndnWA) [in Australian English "zed" is a near neighbour to X in the alphabet]

[Delgarde]

So does this allow X apps to run under a Wayland environment or Wayland apps under X...or am I completely off the page? Please note that this is a serious question, and I am not trying to flan any flames here.

Basically, XWayland is the X server component for running X11 apps under a Wayland desktop, just like there are X servers for Windows, or MacOS desktops... all of which are separate from the one that runs directly on hardware, which is the one traditionally used for a Linux X11 environment. XWayland is used by pretty much all Wayland desktops - but the keyword here is "standalone". Previously the XWayland code was closely tied to the old XServer, but they've been working to separate them, so they can be developed and distributed independently... which is important, since the latter is essentially unmaintained at this point.

[vladimir86]

X is dead.

actually no.

[kon14]

Whats wrong with this? Once the new debian release is out in a few months, it will be more up to date that Ubuntu LTS.

For a few months anyway*

[skeevy420]

Do you know what is "SID"?

Suddenly Inconsistent Debian?

[You-]

For a few months anyway*

As next ubuntu LTS is in 2022, for a year. Ubuntu LTS and Debian will leapfrog each other.

[kon14]

As next ubuntu LTS is in 2022, for a year. Ubuntu LTS and Debian will leapfrog each other.

My bad, I assumed this was about distro releases in general and completely missed the LTS part.
How's the current situation with regular stable/testing/sid branches compared to semi-yearly releases like that of Ubuntu though?
For desktop use cases, LTS releases are, IMHO, a cancer to be avoided at all costs and package pinning hasn't really worked out for me in the past.

[lyamc]

How's the current situation with regular stable/testing/sid branches compared to semi-yearly releases like that of Ubuntu though?
For desktop use cases, LTS releases are, IMHO, a cancer to be avoided at all costs and package pinning hasn't really worked out for me in the past.

LTS has been good for me at least. As Ubuntu transition more towards snap packages, the package pinning issue will become less of a concern.

[kon14]

LTS has been good for me at least. As Ubuntu transition more towards snap packages, the package pinning issue will become less of a concern.

This is irrelevant though. I was specifically asking about Debian's branches.