KDE's Nate Graham On X11 Being A Bad Platform & The Wayland Future

[Damnshock]

Then prove your lies moron!



And another lie, moron. There are no hacks needed. Yes, you'll have to implement a Wayland protocol that is not finished 100 %, but that's it. X will never be able to handle HDR, as HDR on X can only work as long as X isn't part of the chain.

Please, don't insult people.

Be kind and polite, we all profit from that

[Damnshock]

Wrong again moron. Better luck next time.

Please, don't insult people

[Damnshock]

No Artim, you are the ridiculous person (also using unnecessary personal attacks). I've been contributing to MATE's bug tracker and reporting issues as I find them, I found an issue in the MATE main menu and it is being worked on. You are assuming that people are not contributing when they are. There is a move by Redhat to disable X11 and force a broken default onto people. MATE's developers are not to blame for this, neither are the users. The issues I am talking about also exist under Wayfire which is meant to be a fully Wayland native environment. If the Wayland native environments are broken, and the non-native environments are broken, then what are users supposed to do? Forcing people into KDE/GNOME is not an acceptable move for a platform that has been entirely about user choice. The reasonable path forward is to continue to support packaging/running X11 while advocating for, and developing on Wayland. The move to Wayland is progressing, but it's still a while off of ready to be the default, and certainly nowhere near ready to be the only display manager offered in distributions.

Please, stop spreading lies.

Redhat doesn't force anything on anybody. They just don't want maintain Xorg. And that is totally legit

[Damnshock]

Wayland needs X11*. Xwayland is an implementation of the X11 protocol, it most certainly is not xorg in wayland. Xorg is an implementation of the X11 protocol.

That is not true. You can easily have a wayland only session. No need for XWayland.

[browseria]

I don't even know how to read that page. It says "staging" or "unstable" on a lot of things, but Wayland seems to be a category on its own.
Ironically, the picture you picked as an example, shows a bit of functionality that is not actually available in Weston. I didn't even know that was possible, I thought Weston was the reference implementation.

bug77 Weston is the reference implementation. Technically "Wayland" is just the Wayland core protocol. If you look at the "Compositor support" section of this page it might look more like what you are expecting. This defines what Wayland is, what every compositor must implement in order to call it Wayland. v1.0.0 was completed 11 years ago, with commit 1f521a4f. Since then, it is essentially unchanged, mostly tweaks, documentation, tests and bug fixes. For a quick summary of the changes since 1.0.0, I would start here.

Everything else people now call "Wayland" really shouldn't be called Wayland, it should be called "free desktop standards" or something similar. Again, Wayland i.e. wayland core protocol is ONLY the protocol that is used for Wayland clients and servers to communicate with each other, nothing else. But through accident/history/laziness/whatever, other things got colloquially lumped in with "Wayland" too, and got confusingly named "wayland-protocols" to separate the "core" from what isn't necessary to implement Wayland.

wayland-protocols adds functionality not available in the wayland core protocol, either completely new functionality or something that extends the functionality of something in wayland core protocol OR wayland-protocols. However, just because something is in wayland-protocols doesn't mean it is officially part of "Wayland" yet; protocols in general have three phases: the development phase, the testing phase, and the stable phase.

In the development phase, a protocol is not officially part of wayland-protocols, but is actively being developed. It may have the "unstable" label attached to it. No-one is required to implement it.

When a protocol has reached a stage where it is ready for wider adoption, it enters the "testing" phase and gets the "staging" label. Implementation of the protocol is encouraged in clients and compositors where the functionality it specifies is wanted.

After a staging protocol has been sufficiently tested in the wild and proven adequate, its maintainers and the community at large may declare it "stable", meaning it is now "officially" considered to be a part of wayland-protocols.

Each page simply lists what is in the protocol, the messages that get passed between client and server and the objects being referenced. So for example, if you look at wayland core protocol you'll find an interface for something called "wl_surface" - the "wl" stands for "wayland" so this defines a wayland surface, a rectangular area that can be displayed on zero or more outputs. A wayland surface has 16 messages total that can be communicated about it, and they are listed next (and indexed on the right side of the page. Note that one of these is set_buffer_scale; all wayland outputs that can be displayed to a user have a "scale" property, you'll also notice it is defined here as an integer. That means in can only take a whole number as a value, e.g., "1", "2", "3", etc.

The page I referenced in my last message was an extension to this wayland core protocol called "fractional-scale-v1". This protocol defines what it means to have a wayland surface with a fraction for a scale instead of an integer. However, this protocol hasn't become "official" yet, it is still in testing phase, hence the staging label and why only Mutter and KWin currently implement it. The others may or may not implement it, depending on whether they think it is a good idea. Only protocols marked "stable" are official, and need to be implemented (if the compositor wants to).

[Mario Junior]

Windows has the most inconsistent and crappy UI I have ever seen!

I think you don't know the difference between an UI and a GRAPHIC STACK.

@

Moreover, kill Xorg once and for all (including XWayland), throw Wayland in the GARBAGE where it belongs and start writing a damn complete and decent replacement for Xorg, for God's sake!

[Artim]

No it's not using an official protocol, this is a protocol developed by the KDE and Valve devs for use until a proper protocol is completed upstream. (source, English - Planet KDE) I get that things are moving fast, but that blog post is only 10 days old so I think it's still safe to say they aren't using anything official yet.

What are you talking about? The text you link literally says the official protocol is close to finishing and they already have it in a KWin branch. Also they are using an experimental Vulkan layer that uses this protocol:

[...] and the upstream color management protocol for that is still not done yet. It’s getting close though! For example I have an implementation for it in a KWin branch, and Victoria Brekenfeld from System76 implemented a Vulkan layer using the protocol [...} which can be used to run some applications and games with non-sRGB colorspaces.

AI is used by gamers every day in the form of DLSS. Ray reconstruction too but that's much more niche. These are nvidia only features, but considering their marketshare it's safe to say AI is a staple for gamers playing anything recent. I certainly hope Nvidia gets dethroned, but that's because I dislike their approach to the open source ecosystem.

Again mixing stuff like crazy. The thing Nvidia hardware is really good at is training AI/ML models. That's what OpenAI, Microsoft and whatever use them for. That's where the big money actually lies. DLSS is merely applying such models. Yes, right now its the best, as FSR doesn't really seem to use any AI and I have no idea what XESS does. But that's litterally peanuts for them. AMD and Intel just started adding AI cores to their chipsets, so they will get there too. But just using the Tensor cores of an Nvidia dGPU for DLSS is literally underwhelming them, as literally smartphones are running AI models for years now.

[Artim]

Im not sure what you read, but again, read the PDF linked



The PDF itself alludes many times that the requirement for HDR is the difference between the whitest whites and the blackest blacks, how many stops an image can show etc. These are defined by the transfer. Additional bitdepth grants you more data between stops, but it does not give you more stops



Bitdepth by itself does not help produce an HDR image, You need to have an appropriate transfer to shape the light intensity along with appropriate bitdepth to prevent banding. It's also worth noting that Dynamic range and Gamut (IE bt.2020) are also two seperate things as stated in this article once again



A high dynamic range image requires the appropriate range in between brightness, to get this, we require an appropriate transfer, PQ scRGB and HLG are HDR transfers, they give us the fine steps between brightness that SDR transfers like srgb, gamma2.2/2.4 etc dont give. scRGB is unique since it uses a linear transfer, but it brute forces dynamic range by just throwing a large bitdepth at the issue requiring 16bits or 32bits of data.

I cant read the wikipedia article, but either it is wrong, or your interpretation of it is.

Yeah, I'm really not teaching you how to read and understand such a simple text. Believe what you want, it doesn't change the fact in the slightest that everything and anything you say about Wayland is just a blatant lie because you can't cope with progress. Go ahead, play with your Windows. You'll never see any progress there, it will only be bloated with more useless half broken features nobody uses, remove more features people actually use and never will be able to give all system apps a unified look. Just until the last people had enough whith their incompetence and moved on.

[Artim]

Please, don't insult people.

Be kind and polite, we all profit from that

Just fuck off. You deal with those morons and teach them not to spread their ridiculous lies.

[Artim]

Please, don't insult people

Zip it, nobody's asking you.