Valve Engineer Mike Blumenkrantz Hoping To Accelerate Wayland Protocol Development

[WileEPyote]

....snip....

They are implemented as experimental, but still more broken than the Windows implementations, and it took many, many months more to get that less than half assed support. I'll take half assed over quarter assed any day, tyvm. Yes, Windows jumps straight in and releases support that may not be perfect, but the point is they release it, and then continually update it to make it better. No matter how you look at it, Windows is far ahead on supporting these features, and will forever continue to be ahead unless Wayland devs get off their high fucking horses and startb pushing for real progress. I mean, Windows has had full VRR support for YEARS now. Wtf is Wayland's excuse?

And Fanboy? No. Just not fucking blind to the actual state of affairs for end users. Devs can bitch all they want about their philosophies, and sit behind their ideals, the problem is, the people that get fucked over are the regular users. Window's half assed approach is still more functional than what we have in Linux. How fucking sad is that? Years later, and linux has LESS than half assed support. All because people won't try to move the ball forward. Get the fuck out of here with your "but it's half assed" bullshit. Everybody is done with the fucking excuses. We see through it. No more excuses are going to fly. Valve made that perfectly clear this week. Shit or get off the pot.

News flash, none of us give a fuck about your beliefs. We just want shit that works.

And I saw you mention "edge cases" in a different quote. a 1000Hz mouse isn't a fucking edge case. That's the fucking norm these days. Is that really how far behind on hardware you are? No fucking wonder you think everything is fine with how Wayland is doing things. 1000Hz mice is coming up on 20 year old technology.

And I did speak with my wallet. I bought a Steam Deck (and of course a shitload of Steam games) because at least they try to give the end user a good experience instead of sitting in their tower lording perfection over all the people that just want to use their shit. I would happily donate to wayland if they actually did what the majority of users want. But they don't. They're too busy lording over their perceived power of their little corner of Linux. Bunch of fucking power hungry children stepping over each other's toes in the complete and total bullshit lie of "perfection."

OH NO! WHAT ARE WE GOING TO DO? THERE'S PEOPLE OUT THERE THAT ACTUALLY WANT TO USE NEW FEATURES! SURELY YOU JEST?!

Wayland is what I use, but it's slow pace is going to further hamper Linux adoption because people actually want to be able to use their brand new shiny hardware to it's fullest extent. Good job chasing people back to Windows, jackasses.

Some of us actually like the bleeding edge of technology. Get the fuck used to it and adapt or die. And funny you should mention it, I do use Arch. As well as Gentoo. I can't code, but I'm not opposed to getting my hands dirty to figure out what's wrong with my bleeding edge system. I mean, other than the fact that there's no fix for half my features not working because it hasn't been implemented by the governing body.

And switch to Windows isn't the right answer. The right answer is for devs to aim to be better than Windows. When it comes to the graphics subsystem, they are failing miserably.

Go fuck yourself with your self righteous bullshit. I'm too smart for you to gaslight.

[access]

This is still possible, KDE has compositor handoff which can neatly support restarting KWin or replacing it with a different compositor entirely (providing applications co-operate)!

https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/

The "Wayland people" I assume you're talking about are GNOME developers, they can support this but they think it's, and I quote, "an absolutely stupid idea": https://gitlab.gnome.org/GNOME/gtk/-..._requests/4073

Painting with a pretty broad brush now, eh? One (1) developer expressed himself in an overly blunt, perhaps very stereotypical German, fashion and was sharply told off by another GNOME developer. But sure "they"…

[access]

[…]

Windows color management and HDR is a mess. What is landing in Wayland sure looks to be better and might even compete with the way Apple does things. But these things are seriously hard to get right and without unlimited funds it takes time 'cause the whole stack needs to support it from the kernel to the compositor… all the while hearding cats/foss developers.

[fitzie]

This is still possible, KDE has compositor handoff which can neatly support restarting KWin or replacing it with a different compositor entirely (providing applications co-operate)!

https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/

The "Wayland people" I assume you're talking about are GNOME developers, they can support this but they think it's, and I quote, "an absolutely stupid idea": https://gitlab.gnome.org/GNOME/gtk/-..._requests/4073

yes, we had it in xorg, we have it in kde, so why isn't it in wayland protocols? the cabal.

[fitzie]

I'm an end-user. I generally care mainly about my own experience on the desktop I'm using

Devs can hash out their own issues with other devs, but at the end of the day I'm using whatever is presented to me pre-compiled. If it doesn't have CSD, I don't care as long as it has a UI (unless a CSD implies real-world performance improvements or something else to improve the user-experience).

I don't quite know mpv's story, but they discussed CSD, "something" happened (not sure if CSD was implemented or what), but today I can use mpv on Wayland with a UI.



I actually needed that about 20 minutes ago when I tried my Wacom tablet out with osu!. Keyboard input stopped working from mostly everything except Alt + F2, already expected r to not work on Wayland but tried it anyway, and it failed successfully

Yeah having session restore and being able to restart the WM would be great (again)!

if you have window borders on mpv, then it's probably using xwayland. see if xkill works on it to be sure (another useful utility that wayland doesnt feel the need to give us).

[Artim]

i love how wayland supporters are like: "Now that I don't have any issue, I don't know why anyone would have any issue at all." There are many serious issues. This article is all about major issues in wayland and the fact that the wayland community is defective in addressing them without incredible hostility/delay tactics.

There are no serious issues. The article is solely about a misguided attempt to accelerate the attempt of getting allegedly vital protocols adopted before they are marked as finished. The issue is only, nothing was ever preventing any of the compositor developers from doing so, and the one frog-protocol that was proposed sounds important, but can't really be that important. After all, after "15 years of Wayland" (as many of you guys just love to point out, completely ignoring that this only looks on a first draft of the protocol and not implementations), Valve seem to be the only ones that ever missed that protocol. Meanwhile, probably a couple million users - exact numbers are always very difficult to get - are using Wayland without any major issues,

[ahrs]

yes, we had it in xorg, we have it in kde, so why isn't it in wayland protocols? the cabal.

It's not a Wayland protocol because it doesn't need to be. KDE has switched from using a modified libwayland to a Mesa extension:

https://invent.kde.org/plasma/kwin/-/wikis/Restarting#mesa

The only thing required is support from compositors and applications and of course you aren't going to get that support from the party that thinks this is stupid.

[Artim]

I'm an end-user. I generally care mainly about my own experience on the desktop I'm using

Devs can hash out their own issues with other devs, but at the end of the day I'm using whatever is presented to me pre-compiled. If it doesn't have CSD, I don't care as long as it has a UI (unless a CSD implies real-world performance improvements or something else to improve the user-experience).

I don't quite know mpv's story, but they discussed CSD, "something" happened (not sure if CSD was implemented or what), but today I can use mpv on Wayland with a UI.

CSD has the big benefit that rendering the decoration all happens in the programs process, not in the WMs process. So instead of having one huge process that needs to take care of all open windows, it's distributed across many processes. In turn, when rendering is stuck for whatever reason in one program, it won't affect other programs. I'd say that's a very big benefit. To do that with SSD, you'd have to run a dedicated renderer for every program, additionally to the renderer that puts together the resulting image to be displayed. At that point there aren't really any large differences to CSD left, and you have to ask yourself why you would even bother with SSD. Also, with SSD it's possible that if you drag around a window fast enough, it's displayed quite borked, because the WM can't catch up with your movements. Of course that's only possible on slower hardware, but with CSD that's just impossible. That's why both macOS and Windows also do CSD (no idea what Android and iOS do).

For example, we used to be able to restart the window manager without shutting down every application. That just -poof- vanished, and wayland people just forgot that life use to be much better dealing with buggy compositors when you didn't have to restart your entire desktop to go along with your day.

I actually needed that about 20 minutes ago when I tried my Wacom tablet out with osu!. Keyboard input stopped working from mostly everything except Alt + F2, already expected r to not work on Wayland but tried it anyway, and it failed successfully

Yeah having session restore and being able to restart the WM would be great (again)!

That is/was only lacking because it simply didn't have high enough priority. To my knowledge, Plasma 6 has fixed this, so it's very likely that this will eventually be added to all DEs/WMs. And before you ask, I doubt this has anything to do with CSD/SSD.

[Artim]

It is about when a window is unresponsive temporarily, I can still move it easily without resorting to inconvenient alternative methods etc. You described a workaround, but it is less than ideal.

Why on earth would I want to be able to move around a frozen window? Sure, the WM/compositor needs to be able to make sure that this window doesn't stay stuck on the top-most layer, but other than that, I don't see any use in this.

An example that I can demonstrate in my own computer: In other applications, Compiz allows me to set a window to display on all workspaces by right clicking on the title bar and select the corresponding item. In a CSD GTK application, GTK doesn't know there is such a feature and doesn't provide such option when I right click on the header bar.

Doesn't sound like it has anything to do with CSD/SSD, but rather just a lack of priority to support this.

What window management functions exist in a GUI environment is best known by the window manager / compositor. Not the GUI applications living within. In theory there can be a protocol or whatever that communicate this sort of stuff across the compositor and client application, then let them be exposed by a CSD GTK application. Unfortunately, I don't see the Gnome team interested in accommodating then glorious GTK ecosystem with other DEs pr other compositors. Another problem is according to the security-first approach of Wayland, some window management functions ought not be fired from a client GUI applications programmatically but only be available to an end user sitting in front of the computer. A GUI application with only CSD will violate such security concept if we let them fire those commands too easily.

That's one of the large benefits of Wayland over X11. They put security first and over time will find solutions to allow any legitimate use case without creating massive security issues. When X11 and its predecessors where created, software security wasn't really a word in any developers head, especially outside the business world. The use case you describe is simply way too niche to be of any priority. So you'll have just to wait or find ways around the issue like going through XWayland. Better be lucky that there are still ways to do this by just using an X session (and alternative WMs). If this wasn't Linux, but Windows or macOS, they'd just have deprecated this, and I doubt even Windows would have kept around any backwards compatibility, unless some very big customer of them needed it.

GTK4+libadwaita is driving a number of Linux communities planning on or actually working on their escape plans. It is funny when you talk as if GTK4+libadwaita is the beloved one.

Yes, by the people that want to just write software, GTK4+libadwaita is extremely beloved. Especially if you look on Flathub, you barely see any apps that don't use that combination. But in the world of people that just live off the scraps of Gnome (**cough** Mint **cough**), theming is an essential part to their identity, which libadwaita makes a bit more difficult (as in you can still easily change the color scheme, but not the whole design language). If they are smart, they keep GTK4 around and just build alternatives to libadwaita, as only klibadwaita depends on GTK4 and higer, but GTK4 doesn't depends on libadwaita. Especially with Mint, that also made as their task to have two distros, one based on Ubuntu LTS and one on Debian, a whole DE they have to transition to Wayland and has to take care of all apps Canonical snap'd, I fear they might bite off a lot more than they can chew if they don't.

The stop-theme-my-app advocacy shows how arrogant and ignorant some software developers are. They are like those web developers in older days that forced their pixel perfect rigid design upon visitors, but ignored others don't use monitors with the same size, resolution, colour contrast, perfect eyesight etc. Those websites looked horribly unreadable for audience outside their own age group, mindset, and fancy expensive hardware.

Funny that libadwaita-based apps, that are literally the result of that movement, aren't only the most modern looking ones, but probably the most adaptable ones. I never tested that, but afaik, at least any libadwaita-based app can adapt seemlessly to any screen size, including smartphones, I think even by default. No idea though if it could technically handle foldables and change size on the fly, but they can adapt. Show me one UI toolkit that can do the same thing in a reliable way that won't look more or less crappy depending on the app in use. And you can still theme libadwaita-based apps, at least the color scheme. Though, Gradience, that was made for this task, has been deprecated. But it still works and anybody could just fork it. So maybe your view on this whole topic is just solely based on your prejudice and not any facts.

[Artim]

The "Wayland people" I assume you're talking about are GNOME developers, they can support this but they think it's, and I quote, "an absolutely stupid idea": https://gitlab.gnome.org/GNOME/gtk/-..._requests/4073

I wouldn't agree with them, though on a few occasions it already helped me that by default Mutter won't recover any apps, and that apps will be closed alltogether once gdm is being restarted. Except when something is really broken, I had a couple of instances in the past months where dolphin (I think, or maybe some other Qt5 program) didn't just freeze, but actually even sending it the kill signal didn't kill it. But as far as I understand, this can only happen when the kill signal is stuck inside the Kernel, so I guess this can only have been a Kernel issue.

On the other hand, while I never really have the need for it, it would be great if they came around and added that feature back.

PS: it doesn't seem what you imply is the whole truth. The proposal was deemed back, but since then, people have been working on it. It will still take a while to become reality, but it's not out of question.