Because it will always use X11 unless you tell it not to.

A lot of Wayland compositors have a GLES 2.0 renderer which should be supported by ancient GPUs. If you try Vulkan based compositors you might be out of luck.

CPU overhead

I highly doubt you can conjure up a Wayland compositor that consumes more than 1% of your CPU, even eye-candy nightmares like Hyprland will not have any significant CPU usage.

In this case X11 is used as a fallback if wayland is not used.

It prefers X11, and Wayland can be enabled through the ozone layer.

What does that even mean?

Btw, how do you do that in wayland?

You don’t have to do anything to use multiple monitors with different refresh rates in Wayland, besides plugging them in.

This has probably been in the works for years, and RISC-V’s profile (RVA23) for proper user application support was only released a few days ago.

“Hate speech is ok as long as it’s against the people I hate”

https://github.com/audacity/audacity/wiki/Roadmap

They’re only waiting for some code restructuring to release 4.0, which includes UI rework.

Well, freedesktop.org is now focused on Wayland (Xorg is not getting HDR, new synchronization protocols, or proper VRR (unless through XWayland), while Wayland is). RedHat RHEL marked Xorg as deprecated last year and will not even support it by next year (RHEL 10). KDE and GNOME also default to Wayland.

https://github.com/Alexays/Waybar/wiki/Examples

He says while using WIFI, phone calls, GPS, and who knows what else every single day.

You can’t escape US Sanctions, no matter what you choose. So it’s whatever.

Politicians when they realize the commercialized espionage they’ve allowed also applies to them:

Ok, lots of Russian trolls out and about.

It’s entirely clear why the change was done, it’s not getting reverted, and using multiple random anonymous accounts to try to “grass root” it by Russian troll factories isn’t going to change anything.

And FYI for the actual innocent bystanders who aren’t troll farm accounts - the “various compliance requirements” are not just a US thing.

If you haven’t heard of Russian sanctions yet, you should try to read the news some day. And by “news”, I don’t mean Russian state-sponsored spam.

As to sending me a revert patch - please use whatever mush you call brains. I’m Finnish. Did you think I’d be *supporting* Russian aggression? Apparently it’s not just lack of real news, it’s lack of history knowledge too.

making the support situation worse

The support situation is so bad that both GCC and LLVM have extensive for RISC-V.

Well technically there’s already a few out there, most notably Alibaba (found in DC-ROMA laptop), but these are slow relative to what’s available in other architectures and are there mostly for developers to test the software and make sure it’s ready for RISC-V. But nothing is stopping from buying one and daily driving it, it would just probably be a horrible experience.

And it does not concern you that this RVA profile is version 23

Not sure where you got that information. There are only 5 RISC-V profiles.

And they are incompatible, with version 23 because they lack instructions?

Like all the x86 CPUs from a few years ago that don’t have all the new extensions? Not supporting new extensions doesn’t mean the CPU is useless, only that it’s worse than new ones, as things should be when there’s progress. Or I guess you throw out your x86 CPU every time Intel/AMD create a new instruction?

So a compiler would have to support at least a certain number of those profiles

Do you think compilers only target one x86 version with one set of instructions? For example in x86, there’s SIMD versions SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, compilers support all of them, and that’s literally just for the SIMD instructions. What’s new?

It’s getting there but running a full on PC is such a complex task over micros or special purpose devices.

Design application ready CPUs are hard, but not really for these companies. The main issue was the need for a standard, given how many optional extensions are available for RISC-V. The RVA profiles fix this problem by giving a set of required extensions to be user-mode application ready, and they have been a thing for a while. However, these were lacking one important capability for modern applications: vector extensions. RISC-V already had SIMD support (similar to what x86 has), but the vector extension is so much better there’s really no need to even bother with it except with some microcontrollers .

The RVA23 profile, ratified 4 days ago, addresses this by adding the vector extension to the list of required extensions for an application ready CPU. This should be enough for running modern applications, so maybe we’ll see some nice stuff in the next 1-2 years.

That’s a good thing, meaning you can design RISC-V CPUs without functionality you don’t need (like microcontrollers that only need basic operations). However, for those who want a complete CPU, there are RVA profiles (latest being RVA23), which are a list of extensions required to be an application-ready CPU. So there’s really just 1 “standard” for general purpose computing, everything else is for specialized products.