The thing about Linux in general is you have a choice and what you prefer may work for you, just as it may not be necessary for someone else. Everyone has an opinion on what is important for their system, for themselves, and that does not generally make it right or wrong.
Yeah, but Fedora is taking this choice away from you.
Yeah, but Fedora is taking this choice away from you.
Fedora themselves are not taking that choice away from you. Fedora KDE spin will implement Wayland by default, while Fedora will continue to support both. Additionally, Xorg will still be available in the repos.
That’s not what was said above.
Sounds like xeyes.
If everyone needed it, I’m sure there would be some way to make it work.
It’s an absurd thing to argue at the end of the day. Necessities will always be supported.
It’s like the value of anything. If there’s demand, there’s a product.
Xorg is deprecated and incorporated into xwayland.
So supported with Wayland, no longer sperate.
That’s not what was said above.
It is important to read the article and not just what is shared on a forum or social media.
A few hours earlier:
Yes. There would be a replacement or workaround… like a widget or extension.
I did say that. Somehow it would be supported, just not via Wayland due to (perceived or not) security.
There’s always a work around to everything if someone really needs something. But my guess is it’s other than you, the list of folks who want or need it is pretty thin.
I don’t get what you’re talking about. If it is impossible, it’s impossible. Even if I could give a million dollar prize to the person who implements it first, nobody would implement it.
If the Wayland protocol explicitly forbids it, the only way it could possibly be implemented is if compositors broke the Wayland protocol, or the Wayland protocol was changed to be something else.
But that is so hypothetical, it’s in the realm of “what if Wayland didn’t suck” 
There was something about possibly using
Pipewire. Just like everything, there’s ways to make it work, possibly, if someone cared enough to make a work around. Just not natively within Wayland.
Well, yeah, by using X11 and ditching Wayland altogether 
That’s what I am doing.
Post x11**
This guy appreciates this odd side-effect; it appears he considers it a utility for helping him detect what applications are running on Xwayland. 
By the way, somebody did get Xeyes working on Wayland:
It looks a bit hacky but…
Also that was over ten years ago, so I doubt the code still holds up.
Screen recording has come a long way and is a well-supported feature at this point, with simple apps like wf-recorder, an OBS plugin called wlrobs-hg, and I think Gnome has their own solution as well.
Remote desktop is bad, I will agree with you on that one. I tried wayvnc and I got a desktop out of it, but it was completely unusable. I tried to reason with it but couldn’t figure out what the deal is. I run the VNC sessions through a Guacamole server so maybe that is a layer too much for it, or perhaps I just set it up wrong. Either way, TigerVNC works great and is super easy to set up. Switching the box from Sway to i3 was a small price to pay to stop fighting that fight.
Some of your use cases seem odd and do not apply to me, but that certainly does not make them any less legitimate. In that vein, I suppose a personal use case of mine which unlikely appeals or seems relevant to anyone else would be:
I have a laptop which has a HiDPI screen that I have determined is best scaled at 1.2 when I am using it on my lap. No problem, I just set it in the config and it works fine. But when I am at my desk, I place it about a foot further away (behind a keyboard) and connect it to a docking station, which has a couple monitors connected to it as well. Since it is further away, I want the scaling to be bigger (I have settled on 1.5 instead of 1.2), but the two monitors I want scaled normally at 1.0. One of the monitors is non-HiDPI.
On Wayland, all of this is absolutely trivial to accomplish. Just a few commands and the displays take whatever settings you want. I have a script that’s just a few lines long assigned to a keybinding (it could just as easily be a udev rule), so when I connect the laptop to the docking station, I just hit the keybinding and it sets up all the displays how I want them. Unplug, reset the config, they switch back. It’s just stupid easy.
On Xorg, this is a great hardship for some reason, and certainly cannot be dialed in as precisely as I like. I mean, what even is this:
Multiple displays
The HiDPI setting applies to the whole desktop, so non-HiDPI external displays show everything too large. However, note that setting different scaling factors for different monitors is already supported in Wayland.
Side display
One workaround is to use xrandr’s
scaleoption. To have a non-HiDPI monitor (on DP1) right of an internal HiDPI display (eDP1), one could run:$ xrandr --output eDP-1 --auto --output DP-1 --auto --scale 2x2 --right-of eDP-1When extending above the internal display, you may see part of the internal display on the external monitor. In that case, specify the position manually.
You may adjust the
sharpnessparameter on your monitor settings to adjust the blur level introduced with scaling.Note:
- Above solution with
--scale 2x2does not work on some NVIDIA cards. No solution is currently available. [14] A potential workaround exists with configuringForceFullCompositionPipeline=Onon theCurrentMetaModevianvidia-settings. For more info see [15].- If you are using the
modesettingdriver you will get mouse flickering. This can be solved by scaling your non-scaled screen by 0.9999x0.9999.Multiple external monitors
There might be some problems in scaling more than one external monitors which have lower dpi than the built-in HiDPI display. In that case, you may want to try downscaling the HiDPI display instead, with e.g.
$ xrandr --output eDP1 --scale 0.5x0.5 --output DP2 --right-of eDP1 --output HDMI1 --right-of DP2In addition, when you downscale the HiDPI display, the font on the HiDPI display will be slightly blurry, but it is a different kind of bluriness compared with the one introduced by upscaling the external displays. You may compare and see which kind of bluriness is less problematic for you.
That’s a whole page of hacky workaround, and oh by the way it doesn’t even give me the scaling I want–it’s just to try to get the displays to be somewhat readable I guess?
I feel like I am drifting in the opposite direction with my web browser–who even needs a PDF reader application anymore, amirite?! I have even uninstalled qBittorrent in favor of qBittorrent-nox–same thing, except instead of launching a GUI app (which apparently will complain to you about Qt in some cases 
) it broadcasts a WebUI at http://localhost:8080. So you can just run qBittorrent in your web browser! 
I created a new feature ticket in Wayland Gitlab. If you don’t agree with Wayland developers, then you can discuss directly in Wayland Gitlab whether the developers can support or not.
Discussion here in the forum is the waste of time.
You’ve made a really good point:
This wouldn’t be easy for app developers, if many different desktop environments created their own different compositors, but they make compatibility with app more difficult. That is my guess.
Since features are implemented on a compositor basis, forget about unified Linux software. With Wayland, all application software has to be tailored to each compositor separately, because each compositor defines its own extensions to the Wayland protocol. So some compositors may support this function to get global screen coordinates, but it will not be universal and each compositor will have a different API. Maintaining complex software is going to be a nightmare.
So much for Wayland being friendly to developers.
Yeah that sounds absolutely insane!
And mind you - it’s a 
speaking here!
It was a nice experiment in extending the Wayland protocol and implementing it in the compositor. For someone who knows what they are doing, it does not seem to be a difficult task. That was over a decade ago, there hasn’t been any progress since.
The problem is all the politics of getting it merged into Wayland and it becoming a standard part of every Wayland compositor. Look at the @Zesko’s link above, it’s uNSafE!
I wrote about it on the KDE forum, and Nathan wrote a nice reply explaining the situation to me.
I’m no expert but from almost any metric Wayland has to be considered a giant failure. Over a decade late, still nowhere near done, a design thats hotly debated and criticized by the most knowledgeable of Linux devs, unlike every other Linux subsystem, and when its finished will have a massive negative feature disparity due to its design, and performance has been crippled over time.
When you look at Windows/MacOS there are not any things that one would say are better than Linux, but the display manager/compositor is certainly one of them - fast, efficient, a ton more features and has been there for decades. Its so solid no one really talks about it, like the memory manager etc - it just works.