Item — HN Reader

> This is wrong, please avoid making these accusations of bad faith, and please do not spread this misinformation about me.

If you could stop being so rude and insulting I could discuss this further with you. _It was you_ who started with "misinformation" even though it was _never_ the author's intent.

> Wayland is not meant to sit at the layer of the stack you're thinking it is. You could be asking for all those features in something else, but that's a different project you'd be talking about and a different project you'd need to be criticizing, not Wayland.

ISVs and game developers need stable APIs to base their applications on and no Linux library or middleware or whatever you want to call it provides it currently, Wayland or not. You seem to be nit-picky as hell without trying to remotely understand what the author wants and has in mind, and that is "write once and be able to run for decades".

Here's the item you're opposed to and calling "misinformation":

> Applications (or GUI toolkits) must implement their own font antialiasing - there's no API for setting system-wide font rendering. Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X. In Wayland all clients (read applications) are totally independent.

Where the hell is misinformation exactly? Do graphical libraries for Wayland use common _shared_ APIs, interfaces and configuration to render fonts? Are those even standardized? Can I be sure that an application which doesn't use GTK/Qt/EFL will use my ~/.config/fontconfig ? No. That's the answer.

OK, they currently all maybe use FreeType/Pango/Cairo/Skia/whatever, but will these libraries be there in 10 years time? Just 15 years ago _nothing_ in Linux used Pango. It was XFT. No bloody standards, no APIs to guarantee anything in the long term. Well, under Windows all Win32 applications render fonts exactly the same (let's not talk about UWP and other fancy crap) using your font antialiasing settings.

BTW, right bloody now, in Fedora 35, GTK, Qt applications and web browsers all render fonts differently. I can upload screenshots for you to see. So much for "misinformation". Oh, God.

OK, let let's call this article which, every time it shows up, gathers hundreds of comments "a load of absolute bullcrap/misinformation" (which you're so fond of) and Linux is perfect.

If you really want to be technical and factual, approach what article says from the same PoV, not "I will _interpret_ this and that this way based on the _status quo_ and call it misinformation".

Good luck and have fun calling everything you disagree with (even though it's not technically false) "misinformation". BTW, you've used "disagree" quite a lot but still call everything "misinformation. Make up your mind already. Either something is dead wrong or not. First you made it abundantly clear that it's _all wrong/false_ and now you're "disagreeing".

Lastly there are 12 items (!) under Wayland, one which you disagree with, yet the whole article is disinformation. OMFG. This certainly invalidates everything.

Sorry, you've rattled me too much to continue.

1 comments

"_It was you_ who started with "misinformation" even though it was _never_ the author's intent."

I am not saying it is your intent, most people who get things wrong are not intending to do so. It still however can be misinformation. I think you are confusing terms, the word "disinformation" is what usually refers to intentional false information. I'm not saying you're spreading disinformation and I'm not criticizing you as a person. My issue is with the words that are written in the article. Please avoid taking criticism of your work personally, I'm sure you are a good and beautiful person.

"ISVs and game developers need stable APIs to base their applications on and no Linux library or middleware or whatever you want to call it provides it currently"

I agree, this is the real problem and you could just state that. It has nothing to do with X or Wayland or whatever.

"what the author wants and has in mind, and that is 'write once and be able to run for decades'"

Actually I do understand this, and I feel the article doesn't communicate it well, I wish you would be clearer about what problems you're having here with shipping apps like this. The criticism of all kind of unrelated things is distracting, just mention what you're trying to run that isn't working.

"Do graphical libraries for Wayland use common _shared_ APIs, interfaces and configuration to render fonts? Are those even standardized?"

The answer to all of those is yes, they use freetype.

"Can I be sure that an application which doesn't use GTK/Qt/EFL will use my ~/.config/fontconfig ? No."

I'm really not sure what you're asking for here, if the app opts out of the standard then of course it won't work. You can also implement your own font rendering on Windows/MacOS and opt out of the standard there too. There is absolutely nothing X or Wayland or Mac or Windows or anything can do if an app decides they are going to implement their own font rendering library. And I assume you're talking about games here, those are a great example of something that intentionally doesn't follow the system settings on any platform.

"OK, they currently all maybe use FreeType/Pango/Cairo/Skia/whatever, but will these libraries be there in 10 years time?"

Well yes, the code will probably still be around, I think github has archived all this stuff for 1000 years or something like that.

"Just 15 years ago _nothing_ in Linux used Pango. It was XFT. No bloody standards, no APIs to guarantee anything in the long term."

I have no idea what you mean, you can still use Xft. Pango has more features however so you'll have to upgrade if you want those. That's generally how it works, new APIs get new features, the old APIs stay the same and remain stable.

"Well, under Windows all Win32 applications render fonts exactly the same (let's not talk about UWP and other fancy crap) using your font antialiasing settings."

I don't understand why you are saying disregard UWP, that would be a demonstration of the same problem!

"gathers hundreds of comments 'a load of absolute bullcrap/misinformation' (which you're so fond of) and Linux is perfect."

Linux isn't perfect, I've said repeatedly that it's heavily flawed.

"Good luck and have fun calling everything you disagree with (even though it's not technically false) "misinformation". BTW, you've used 'disagree' quite a lot but still call everything "misinformation. Make up your mind already. Either something is dead wrong or not. First you made it abundantly clear that it's _all wrong/false_ and now you're 'disagreeing'. Sorry, you've rattled me too much to continue. "

Please avoid this kind of combative comment. I've said I agree with you in subjective matters in what constitutes being "good" or "bad" and what we think needs to happen. In matters of the facts of what the software actually is doing right now, that's where we need to worry about facts and misinformation. You owe it to your readers to be as accurate as possible if you want to have a positive effect. Also I apologize if you feel rattled, it's not my intent to upset you, my intent is to get the facts corrected.

Anyway I'll get into it. From my perspective from actually working on this, the problem with most of these statements is that none of these things can actually be fixed in Wayland. Wayland is just a really basic protocol for putting buffers on the screen, it doesn't do much else and it's intentionally not good at being a general purpose API for desktop-y things. Your article seems to assume that it is, which is a misconception, and only causes confusion. If you actually tried to fix these problems by making changes in Wayland then you would make the problem worse. Most of what is mentioned absolutely are problems, but they need to be fixed elsewhere, and the claim should probably be rephrased to reflect that if you want it to be accurate. To be clear, I am in no way trying to downplay any of these problems.

"Wayland doesn't provide multiple APIs for various crucial desktop features"

So some of these are in the portal API, not wayland. It doesn't really make sense to put them in Wayland, some implementations do provide them in Wayland but that's more of an implementation detail and applications wouldn't actually be expected to use that API. Some of them are still missing from the portal API however, which is a problem, so maybe this should be edited down to just those. I'll talk about each of them too.

- global keyboard shortcuts - It's not clear what this means. There were some proposals for this but none adequately explained the problem.

- drag-n-drop - Not sure what else you're looking for here, Wayland has this.

- systray - There are implementations of this, it doesn't belong in the wayland protocol. It would be for a panel to communicate with an app.

- screenshotting, screencasting - This is in the portal API.

- UI rendering acceleration - Not sure what this means, Wayland clients can just use OpenGL or Vulkan.

"which must be implemented by the window manager/compositor, which means multiple applications using the said features can only support their own Wayland compositor implementations"

I'm not sure what this means, applications can use an abstraction layer that deals with it for them. Most applications already are using such an abstraction layer like GTK/Qt/SDL/etc, they should not have to deal with the raw X11/Wayland API.

"Wayland doesn't provide a universal basic window compositor"

This is not the use case of Wayland and it would not be possible for Wayland to provide this. You could build such a compositor on top of Wayland.

"thus each desktop environment has to reinvent the wheel and some environments simply don't have enough manpower to write a compositor e.g. XFCE/IceWM. This also leads to a huge amount of duplication of work (and bugs as well) because various desktop environments need to reimplemen the same features and APIs over and over again."

Well no, if they're short on manpower they can just use an existing compositor such as Mir, wlroots, mutter, etc. The real problem here is that they are short on manpower, nothing can be done in Wayland or X11 or anything to really fix that.

"Wayland and its window managers/compositors have very high requirements in terms of support from both hardware and kernel drivers which prevents it from working on far too many configurations. X.org and Windows on the other hand can work on an actual rock using e.g. VESA."

So this is an actual problem but it's not really related to Wayland, e.g. if you want to run an X compositor on an old PC that will also have bad performance because it requires hardware acceleration. And if an app itself requires Vulkan or something then that definitely won't work. I'm not sure what can be done about this and this seems like complaining about an unsolveable problem, you will also have similar problems if you try to install Windows 11 or MacOS Monterey on an old PC and try to run modern apps on it.

"Applications (or GUI toolkits) must implement their own font antialiasing"

This is completely wrong, basically all applications and UI toolkits just use freetype.

"there's no API for setting system-wide font rendering"

This is also completely wrong, this is what fontconfig is for. It's not the best API though so this section could be rephrased as a review of freetype and fontconfig.

"Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X."

This is also completely wrong, I just checked Android and MacOS and there is no setting to change the font rendering. Not sure about Windows as I don't use it.

"Wayland does not provide a basic universal unified graphical toolkit/API (and Wayland developers will not implement it)"

See what I said above, Wayland cannot implement this. If you wanted this you would have to build it on top of Wayland. Wayland is a API to use when implementing a toolkit.

"akin to Win32 which means applications using different toolkits (e.g. Qt, GTK, Enlightenment) may look and behave differently and there's no way to configure all of them once and for all."

Toolkit fragmentation is a real thing which should be mentioned in this article, but see above again, this is not something that Wayland is ever going to be in any position to fix.

"Firstly, forget about performance/bandwidth efficient RDP protocol (it's already implemented but it works by sending the updates of large chunks of the screen, i.e. a lot like old highly inefficient VNC)"

Another thing that Wayland is not in the position to fix. This would be nice to have but would be up to the toolkits to implement.

"forget about OpenGL pass-through, forget about raw compressed video pass-through"

This has to be implemented in the VM host, there is nothing a Wayland implementation can really do about it. The Wayland protocol only receives the dmabufs and YUV buffers and passes them off, it doesn't say anything about what to do with them.

"In case you're interested all these features work in Microsoft's RDP."

Yeah so that would be a problem with the RDP implementation, FreeDRP or whatever.

"Secondly, forget about proper output rotation/scaling/ratio change."

That thread is really confusing and nonsensical to me. If you have non square pixels then you just make the application aware of the vertical/horizontal DPI in some way. Wayland doesn't even need to get involved, it will just display your buffer as you pass it. Wayland itself doesn't assign any unit to a pixel.

"Wayland doesn't allow XWayland applications to change display resolution which could make running games slower as the compositor needs to upscale each game frame."

This is more of a problem with X11 since there is no "safe" API to change the display resolution there. Maybe someone could fix it but those apps really need to be ported to a different API.

"Also software upscaling might not be the best option."

Well most compositors are using hardware upscaling.

"Wayland doesn't allow applications to exclusively grab mouse/keyboard which is required for games and applications like VMs."

This is wrong, that's what the pointer constraints protocol is for.

"Applies to the X server/protocol as well: neither X.org, nor Wayland window managers offer a way to extend/modify window's title bars and File Open/Save dialogs."

This again has nothing to do with X.org or Wayland. The title bars and file dialogs are handled by the toolkit.

"there's no unified toolkit and no unified window manager (or protocol)."

So I think you could just replace this entire section with this statement and then go from there.

"Wayland compositors don't have a universal method of storing and configuring screen/session/keyboard/mouse settings."

This one's potentially a real problem, but again, it's not clear what "screen/session/keyboard/mouse settings" are. That could be thousands of things. And this also has nothing to do with Wayland because it's not a protocol for configuring settings.

"Currently there's no standard way to remap keys under Wayland."

See above, this has nothing to do with Wayland.

"Wayland applications cannot run without a Wayland compositor and in case it crashes, all the running apps die."

This statement is badly worded, technically this isn't true and it just needs to be implemented. Which is the real problem and is currently underway, see here: https://lists.freedesktop.org/archives/wayland-devel/2021-Au...

"An assortment of various other general and KDE specific issues."

These are valid issues, please make these issues more prominent.

And just a few more things.

The sections on video drivers, printers, Xorg and Linux kernel I think are mostly correct but I would say you probably want to remove any paragraphs that have no sources, or ones that have low quality sources. Random Slashdot and Reddit posts are not a reliable source, and it makes your article look sloppy. It's not responsible to put that information out there with nonexistient/bad sources, so probably take those paragraphs out and put them back in once reliable sources are located. It would be best to have a tracking issue or official statement from the developers for each of those problems.

I think this article is good for maybe a first draft but it needs a lot more editing to really be a powerful piece. You are clearly a smart and capable person and you can do much better than this. You may even want to take it down completely until everything is fixed. I had some other issues but I can't remember what they were, and in any case I think you have enough to work with here. So I'm looking forward to getting these corrected and seeing future revisions of this article. Just let me know if you need more help, thanks.

Wayland and Xorg sections have been reworked. Most of your Wayland concerns have been addressed (but not all).

If you still have other concerns and want to contribute, please do.

Only like I said before, let's talk about items which are _factually wrong right now_ as we speak.

> you probably want to remove any paragraphs that have no sources, or ones that have low quality sources. Random Slashdot and Reddit posts are not a reliable source, and it makes your article look sloppy.

Since there are no official/factual sources but the sentiment is shared by lots of people, what would you do about that? To think about that, _nothing_ in the article has rock-solid proofs or sources. If we continue along those lines, it should simply not exist as it's so effing "bad" yet it's common knowledge that 1) APIs in Linux are abandoned all the time 2) There's nothing similar to Win32 3) There are tons of regressions all the time 4) HW support is spotty at best despite to the proclamations of the opposite 5) Lots of bugs in core applications e.g. DEs 5) Older applications are abandoned with no official way to run them - and people debate even these things based on anecdata, "Linux works for me which means it's perfect".

> It would be best to have a tracking issue or official statement from the developers for each of those problems.

No one cares. Most developers will oppose to this idea HARD. The list has existed since 2009. If anything has been solved on it it was due to developers being _personally_ annoyed by the said issues. Not because the Open Source community demanded it, or someone paid attention to bug reports, no, it was either developers addressing bugs which affected them or companies like Valve sponsoring the things they need (wine/Proton/DXVK).

> I think this article is good for maybe a first draft but it needs a lot more editing to really be a powerful piece.

Nah, just "misinformation". I will never forgive you for using this word, as I have a very strong attitude about people who use it willy-nilly to talk about anything they merely _disagree_ with.

While I'm totally OK with people having different opinions about something which has not been established or proven scientifically, there can be no opinions about something which has been conclusively proven, e.g. evolution, climate change, gravity, etc. etc. etc. You do not debate something which has long become the scientific fact. The author has a scientific background, opposes religions and loves science, so to think that he's willingly spreading misinformation is an insult of insane proportions.

> You may even want to take it down completely until everything is fixed.

Nah, your posts will be reviewed later, if there's truly valuable, meaning it's really good in terms of refuting the article head-on, it will be addressed just like it's been done before. If you find the article so repulsive, don't visit this abomination made of falsehoods. Sorry for kinda overreacting but you started off horribly.

Likely everything that goes under "I disagree because", "This happens because" followed by mostly inane "arguments" why Linux is "different" from well-established OS'es with good stable APIs and excellent documentation, will not be addressed because your opinion, while it's very deer to you, does _not_ solve or address the issues presented therein. Open Source fans have a long list of opinions about Open Source, almost none of which have helped address anything since 1991. Most open source fans love to think of themselves as selected few who are so great for choosing open source, yet absolute most of them haven't contributed in any way shape or form. The guy who wrote this ugly largly false article (according to you) has helped resolve hundreds of bugs including in the Linux kernel, GCC, Xorg and other core Linux projects. Applying the word "misinformation" to his work and efforts is terribly insincere, damning and extremely insulting.

> I had some other issues but I can't remember what they were, and in any case I think you have enough to work with here. So I'm looking forward to getting these corrected and seeing future revisions of this article. Just let me know if you need more help, thanks.

Slow and steady.

> the portal API

I don't care about lightweight virtualization solutions, I care about native applications. If we start talking about virtualization, let's forget about Linux as a software platform altogether. Why would anyone want to run Linux if you can run Flatpaks under Windows, FreeBSD, etc. etc. etc. not to mention increased memory consumption, disk consumption, slower startup, and ... ISVs just don't like it. They like to compile native applications and be done with that like they do for Windows, MacOS, Android and iOS.

> - systray - There are implementations of this

Exactly, "implementations" - which means you cannot write an app which could run under all Wayland DEs and minimize to the systray. This is not an issue under Xorg Windows MacOS - only under Wayland.

> global keyboard shortcuts - It's not clear what this means. There were some proposals for this but none adequately explained the problem.

"proposals", exactly, no APIs, no standard way to make 'em work in all Wayland compositors.

> drag-n-drop

Removed.

> screenshotting, screencasting - This is in the portal API.

Again, Flatpak.

> UI rendering acceleration - Not sure what this means, Wayland clients can just use OpenGL or Vulkan.

It means under Windows you use Win32/D3D and as a programmer you don't have to think how to make your application run fast using system wide GPU hardware acceleration. Again, there's no common API underneath GTK, Qt, EFL which provides it which means a zoo of implementations, bugs and problems.

Still, you're right, it has nothing to do with Wayland, so moved to a new section and rephrased! Good point.

> I'm not sure what this means, applications can use an abstraction layer that deals with it for them.

Doesn't exist currently.

> Well no, if they're short on manpower they can just use an existing compositor such as Mir, wlroots, mutter, etc.

Their lead programmers think otherwise or they would have started using them a long time ago. Please argue with them. Is this an issue right now? YES!

> I'm not sure what can be done about this and this seems like complaining about an unsolveable problem, you will also have similar problems if you try to install Windows 11 or MacOS Monterey on an old PC and try to run modern apps on it.

Windows and X.org both can run on VESA compatible GPUs, that also means you have safe mode in case your graphical driver misbehaves. No such option with Wayland compositors. Is this an issue with Wayland itself? No. Is this a valid current issue? Yes.

> This is completely wrong, basically all applications and UI toolkits just use freetype.

Already mentioned that GTK Qt EFL based applications and Web browsers here on this PC render fonts differently despite all using FreeType. They don't just use FreeType, there's no such thing as "just using FreeType".

> This is also completely wrong, this is what fontconfig is for. It's not the best API though so this section could be rephrased as a review of freetype and fontconfig.

See the previous paragraph. I don't care why they look different and render fonts differently, but the issue remains.

> This is also completely wrong, I just checked Android and MacOS and there is no setting to change the font rendering. Not sure about Windows as I don't use it.

In Android all apps look exactly the same to me. In MacOS last time I used it all apps looked exactly the same. In Windows: classic Win32 applications all look the same: https://www.thewindowsclub.com/disable-font-smoothing-window...

> See what I said above, Wayland cannot implement this. If you wanted this you would have to build it on top of Wayland. Wayland is a API to use when implementing a toolkit.

> Toolkit fragmentation is a real thing which should be mentioned in this article, but see above again, this is not something that Wayland is ever going to be in any position to fix.

Addressed.

> Maybe someone could fix it but those apps really need to be ported to a different API.

Windows has moved from GDI to WDM 1/2/3 transparently and most old applications continue to work. Not a good argument, sorry.

> Well most compositors are using hardware upscaling.

Addressed/removed.

> This is wrong, that's what the pointer constraints protocol is for.

Can you provide more info please?

> This again has nothing to do with X.org or Wayland. The title bars and file dialogs are handled by the toolkit.

> So I think you could just replace this entire section with this statement and then go from there.

Moved/addressed.

> This one's potentially a real problem, but again, it's not clear what "screen/session/keyboard/mouse settings" are. That could be thousands of things. And this also has nothing to do with Wayland because it's not a protocol for configuring settings.

Does Wayland necessitate a compositor implementation for the user? Yes. Does the user want to configure each of dozen possible compositors? Very unlikely, they want to configure their graphics and related settings once and for all.

> See above, this has nothing to do with Wayland.

I've lost you here.

> This statement is badly worded, technically this isn't true and it just needs to be implemented.

Is this an issue RIGHT NOW? Yes.

> These are valid issues, please make these issues more prominent.

Copying and pasting is not my forte.

-------------------------------------------------------

P.S. I beg you - please stop talking about "this needs to be implemented", "this could work if", etc. - expressions like these unfortunately prove it right.

You started with "misinformation" yet the article describes the CURRENT ISSUES plaguing Linux on the desktop.

If you want to actually make a difference (about the article), start talking about _the status quo_.