Are there any major x11 features that wayland lacks other than remote operation over a network? I think at one point it locked the refresh rate to 60hz, has that been changed?
For gaming, the latency is bad and always on vsync is horrible. They've fixed the 60Hz lock though, fortunately. This only applies to gaming though.
My primary issue with Wayland isn't quite so much that it lacks these things, it's that they seem to be of the opinion that there's only one way to do things, and any other use of the visual display system is wrong. I just have this weirdly oppressive feeling about my inability to configure it the way I want it, the same feeling I get from using Windows. Just... let me be me. I get that this is a non-technical complaint, and that it ultimately boils down to "it gives me the heebie jeebies" which isn't an argument, but it's still how I feel about it.
So there is no way for a game to bypass wayland and write directly to the fullscreen framebuffer? You're just stuck with an extra frame or two of latency?
I'm not sure how graceful the alt+tab behavior of this approach would be though.
This is especially true for people that prefer low latency over tear-free rendering.
? what? you mixed systemd with wayland maybe, everyone knows that wayland is a protocol, this is repeated 100 times in each thread , everyone also knows that most of X features are not part of wayland
Wayland requires* everything to be monolithically built into the display server (which is also the window manager), which means if I want to use a new WM (say, XMonad) I need to reimplement all of this stuff. Want screenshots? Build it into your WM! Want redshift? Build it into your WM! The result is that development effort will be wasted reimplementing "competing Wayland implementations" stuff that no-one actually wants.
Compare X11, where I could run an Xorg server together with any of a number of lightweight window managers, and the window manager is only responsible for, y'know, managing windows, and determining how the window decorations look. Xorg handles everything else, allowing a robust marketplace of competing WMs to arise.
* Unless/until they finally give in and standardise protocol extensions for out of process window managers.
I've been running Wayland gnome-shell on Fedora since Fedora 25, on a Dell m3800 and now a Dell XPS 15, both with 4K internal displays. I often connect to external monitors or projectors, either 1080p or 4K.
Wayland has better HiDPI support than X and has for a long time.
In order to make X work in any reasonable way you need to configure X to render at 4K all the time on all outputs and downscale using xrandr on 1080p displays. X cannot handle different DPI settings.
Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?
Sway/wlroots.
> Consistent window decorations?
This is up to individual compositors and toolkits.
> Thousands of applications
Like what? Any that rely on X specific behaviour run via XWayland.
> Consistent performance
Wayland in theory should be faster than X, but again, this depends on compositor.
> Redshift
Gnome has night-light on Wayland already. KDE I think just added it.
> Global keybindings
There are proposals to allow better negotiation of key bindings. But I think it's a bonus that applications can't listen into keys when they're not in focus.
Wayland ecosystem is literally decades away from being usable and it's very unlikely to survive those decades beyond maybe being a niche project for some special purpose devices, not linux desktop though.
As for those other things you mention (xprop, etc.), I don't even know what they are, so I assume I've never used them.
I think you underestimate the degree to which desktop Linux users just want a working system with sane defaults. Maybe you personally value having all the knobs to twiddle, but I'd suggest you're an outlier.
I maintain an embedded Linux system which uses Wayland as a compositor for Qt. I use sysfs to EG turn off cursors and set the display mode so I can blit a splashscreen. And sysfs can be used to rotate the console, change display modes, etc..
On my desktop I don't use any of the tools you're listing and haven't needed then for almost 12 years. The wm handles that for me.
I have used Linux desktops for years and have quite literally never used any of those things (except for non-Gnome DE, which was slightly less "don't make me think" so I eventually went back to gnome). Yes, even xterm. Other tools might have been shelling out to those other utilities you mentioned for me, I guess?
Point is, there are at least some reasonable use cases that don't engage with that stuff. I truly don't know how much of the display stack of my current distro is X or Wayland-related code; I have never had reason to care. I don't have a dog in this particular fight, but there are lots of users who use Linux desktops not because they are customizable, modular, or whatever, but because a) it's a free OS, and b) it's similar to environments we target for development at our jobs. Despite the vocal-ness of customization advocates, I suspect that the vast majority of desktop Linux users are "dark matter" that fall into this category.
There's a large group of users that goes to great lengths to customize their desktop experience. This kind of change understandably frustrates them. But it's important to understand that many of us just don't care very much.
Can it run gnome-terminal and Firefox? Can I switch resolutions and do multiple displays? That covers a vast majority of what I ever need from a graphical desktop. Beyond that I don't really care how the sausage is made.
I would argue that not having to use those tools to have a happy working environment makes it further advanced, rather than behind.
There are applications that do not run as a window, in present I have a global shortcuts that run a bash or python script, I know I am a power user so I will need a way to whitelist my use case.
GNOME and I'm pretty sure KDE too has a method to set custom keyboard shortcuts that can execute commands.
Yeah, that is the problem with Wayland: the solution to many missing features you get out of the box with X largely depends on the environment you are using.
Wayland needs to offer full access to "power users applications" if not we end up where Windows will be more friendly for the users that need this type of applications
> Sway/wlroots.
So you either have to use one of the prescribed Wayland window managers, or completely rewrite your favourite window manager (remembering to include all of the bonus responsibilities it has now for everything the Wayland developers decided was "out of scope and the compositor's responsibility").
Alright, five years of work and debugging later...
> > Consistent window decorations?
> This is up to individual compositors and toolkits.
So it won't be consistent.
> > Consistent performance
> Wayland in theory should be faster than X, but again, this depends on compositor.
So this is the part where you go back to the window manager you wrote in step 1, and fix all the performance problems (collectively, over and over again, for every window manager that exists), right?
> > Redshift
> Gnome has night-light on Wayland already. KDE I think just added it.
Great! What if I'm not using Gnome or KDE? Right, I need to code that into my window manager too...
The decision to leave window decorations up to the client application rather than the window manager is incomprehensible to me. It just doesn't make any sense so far as I can tell.
I don't want to run GNOME or KDE to get redshift behaviour; I want to run a window manager written in Lisp, with a console, emacs & Firefox. Everything else is a distraction from getting work done.
I agree that not allowing clients to listen to all keys by default is good; I disagree that not providing a mechanism for the end user to grant such access is a good idea. It's his computer — let him run what he wants.
https://github.com/sdilts/mahogany
Maybe you're interested in helping?
>Consistent window decorations?
We have a protocol for this for compositors that want to support it: https://gitlab.freedesktop.org/wayland/wayland-protocols/tre...
>Redshift?
Works on GNOME, KDE and Sway.
>Global keybindings?
We prefer to let users configure those in their compositor's configuration file.
* Screen recording apps are therefore largely just nice frontends on whatever primitives the compositor exposes to do screen recording.
* GNOME speaks dbus and exposes those primitives as dbus services.
* So you need to speak dbus.
You can't really avoid dbus without going really far out of your way these days. Unless something better comes along it's going to be the Linux messaging passing system.
Ask yourself, "why do all of the major GUI systems - in daily use by billions of people, evolved over the past 40 years - opt to offer remote operation only as an optional add-on?"
Maintainers, beware of the tail wagging the dog!
I'm not dismissing the need. I'm just saying that the other systems work pretty well, and this is not something that needs to be baked into the core of the display system.
I used and loved Screenhero on the Mac for years before Slack swallowed them up. (Now there's tuple.app, made by some of the same people.)
Prior to that, I used Windows RDP for years. That worked pretty well, too!
But why are you so opposed to having this featured backed into the display system? After all you point out yourself that all display systems and up with solutions for this work flow. Why not do it right and build it into the display system instead of adding it after that fact (and usually in an inferior qay)?
"The X11 protocol was never meant to handle graphically (in terms of bitmaps/textures) intensive operations. Back in the day when X11 was first designed computer graphics were a lot simpler than they are today.
Basically X11 doesn't send the screen to your computer, but it sends the display-instructions so the X-server on your local computer can re-create the screen on your local system. And this needs to be done on each change/refresh of the display. So your computer receives a stream of instructions like "draw line in this color from coordinates x,y to (xx,yy), draw rectangle W pixels wide, H pixels high with upper-left corner at (x,y), etc." The local client isn't really aware what needs to be updated and the remote system has very little information on what the client actually needs, so basically the server must send a lot of redundant information that the client may or may not need. This is very efficient if the display to be rendered consists of a limited number of simple graphical shapes and only a low refresh frequency (no animations and such) is needed. Which was the case back in the days when X11 was first developed.
But modern GUI's have a lot of eye-candy and much of that needs to be send from the remote system to your client in the form of bitmaps/textures/fonts which take quite a lot of bandwidth. And all sorts of eye-candy includes animated effects requiring frequent updates. And the displays keep getting bigger too, twice as wide/high is 4x the number of pixels.
Of course, over time, enhancements to the X11 protocol were made to optimize this as much as possible, but the basic underlying design is, in essence, simply not well suited to the demands of the kind of GUI's people nowadays expect.
Other protocols (like RDP and VNC) are more designed to let the remote system do all the hard work and let that system decide which updates to send to the client (as compressed bitmaps) as efficiently as possible. Often that turns out to be more efficient for modern GUI's.
Neither method is perfect and can deal with every situation equally well. There is no such thing as a single display-protocol that can do well under every conceivable use-case. So in most cases you just try all protocols that are supported between your local client and the remote server and use the one that gives the best results. And in some cases there is no choice and you just have to make do with whatever is available.
Most protocols do allow some performance tuning, but many of these settings are server-side only and not available to the average user. (And configuring them properly is a bit of an arcane art. A lot of sys-admins won't be willing to mess with that.)
In most cases the easiest way to improve performance (sometimes quite dramatically) is by switching to a more simple desktop environment with less eye-candy and forego the use of background images."
Why have ALL of the other major systems - Windows/ReactOS, NeXT/Mac, BeOS/Haiku, iOS, Android, etc. - not bothered with implementing network transparency in the core of their display systems?
Mind you, I'm not asking the question of why the people that made these systems all decided against building on X11. (That was answered ages ago by an Apple employee posting on Slashdot: https://developers.slashdot.org/comments.pl?sid=75257&cid=67...)
I'm sure that you could build a new system that has this network transparency feature. But I wonder how one would avoid failing the way that previous efforts failed:
- Y window system (http://www.hungry.com/old-hungry/products/Ywindows/)
- Berlin Project (https://web.archive.org/web/20041030075704/http://www.fresco...)
These things had network transparency, and they went absolutely nowhere...
Perhaps people might be interested in porting Haiku's graphics system to Linux to replace X11?
If your application can draw its frame and get its notification into the compositor before the compositor begins to draw, there's no need for any additional delays.
If your app cannot complete a draw in the time left in the frame by the compositor, then it'll be one frame behind.