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?
HiDPI. It's somewhat unusual for a top end laptop to have 1920x1080 screens these days, and Wayland doesn't support 4k very well. You can upscale, but it looks like garbage, or it has a 2x mode, which draws image and such slightly too large, or you can deal with everything being tiny.
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.
>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.
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?
That is the problem right? Whenever there is a functionality that you could get with X11 by tweaking configurations files you have to write you own complete new Display Server in Wayland to have that functionality.
This is especially true for people that prefer low latency over tear-free rendering.
I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic. Now, people complain about there being competing Wayland implementations with different feature sets. What's it gonna be, guys?
>I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic
? 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
Those complaints aren't actually opposed but perfectly complement each other.
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 don't think any of those problems can be solved solely in the compositor - they all require co-operation between it and the actual apps. Which means, in practice, that you'd probably have to create an entirely new version of the Wayland API for creating and managing windows, add it to all the compositors, and get all the apps to use it too, on top of all the other work involved in fixing those issues. (This is the only real way to extend the protocol and has already been done a few times - the most recent one I remember was to add the ability to minimize windows.)
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.
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.
I always wonder how people use their linux desktops when they claim that wayland works. Why aren't you using anything like wmctrl, xdotool, xprop, xbindkeys, xterm? Or non-Gnome DE? Don't you need custom keybindings for multiple keyboard layouts with caps/scroll led indication? Don't use wacom devices or anything like it?
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.
A lot of the things that Stack Overflow claims you need X tools for can also be accomplished using sysfs. Without knowing the details of what you're doing I can't give you any specifics.
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.
> Why aren't you using anything like wmctrl, xdotool, xprop, xbindkeys, xterm? Or non-Gnome DE? Don't you need custom keybindings for multiple keyboard layouts with caps/scroll led indication?
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.
I've used Wayland and Gnome ever since they became available in Arch Linux, and I've never needed or missed any of those things. Yes early on there were some annoying bugs but this is life on the bleeding edge ;) These days it all just works.
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 haven't touched any of those tools in a decade or more. I just haven't needed to? The Linux desktop is so much less demanding than it was through the 90s and early 2000s. You don't need to know about any of that stuff to make it work, to customize things, set your favorite key settings (e.g. making Caps Lock useful), to have reasonable hotkeys, etc.
I would argue that not having to use those tools to have a happy working environment makes it further advanced, rather than behind.
>But I think it's a bonus that applications can't listen into keys when they're not in focus.
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.
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.
I don't run a desktop environment in X. I run xmonad and terminals. I don't want a desktop environment in wayland, but it seems like that's the only way to get reasonable functionality because it can't be added piecemeal, only monolithically via the compositor.
This is not enough. you fix this use case but there are many others, maybe I want to make a voice/video chat app or a remote desktop app, I will need full control of the display and keyboards not some gimped implementation that is DE specific.
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
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...
Sway/wlroots aren't written in Common Lisp, like StumpWM.
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.
As far as I know not into the wayland protocol itself. The devs have been pretty adamant that wayland is 'just the compositor' and left the rest as an exercise for the community, or the toolkit developers. So for instance there is https://github.com/foss-project/green-recorder but as far as I can tell on wayland it only works for gnome, and requires dbus to work (wat?!).
* Screen recording is a privileged operation in Wayland which is left to compositors to implement as they see fit.
* 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.
The wlroots developers have proposed protocols for screen grabbing etc. which are already supported by some window managers (e.g. Sway) and by some applications.
I don't use remote operation (as imagined by X11) at all. But I do use non-X11 screen-sharing systems all the time.
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?"
And I use remote operations all day every day. As does the entire department with hundreds of people. Don't dismiss other peoples works flows without understanding them.
(I ran Linux + X11 as my sole desktop from 1996-2000. And then on and off again for years in VMs.)
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!
Sorry if I misread your comment and thanks for editing it to make it clearer.
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)?
I'm against baking it in precisely because it's not the right thing. Network transparency in X11 led to a design that didn't scale to meet the needs of the vast majority of users:
"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."
Sorry, but a stack overflow answer (that doesn't even seem to be written by you) that give a bad overview over how X11 does it is not an explanation of why it can not be done. Or why it should not be done given that all platforms develop abilities to do exactly what I ask for at some point anyway.
First, I never claimed that the quote was written by me! That's what the quote marks and link are for.
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?
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:
Blub paradox. If you habitually confine yourself to a single computer, remoting never becomes a tool you reach for. NeXT had remoting because it was meant for power users in labs full of closely networked workstations.
Not sure what you're talking about here, Haiku's window system has network transparency, with drawcall-forwarding, even. In fact there is an HTML5-based remote client for it!
Probably not. The entire reason that the remote-drawing works is that the draw calls are passed through all the way up from the widgets and controls layer; for apps that don't use those (e.g. Qt apps, etc.) it's just a dumber VNC (we could make it less dumb, but, a little starved for time right now.) So then you would be porting the entire Haiku toolkit to Linux ... and at that point why not just use Haiku? We have our own kernel for a reason :)
swaywm supports screenshots and screen capture for sure [0]. I haven't personally done anything with screen capture on sway, but I can definitely confirm that grim works for screenshots.
And the latency depends on the compositor. I believe Arcan achieved 0 frame compositor latency with Wayland. I think the latest gnome-shell Mutter is there as well.
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.
How is gaming in it? Steam games? 3D accelerated games? Games in wine? Fullscreen games? Different resolutions? Alt tabbing between game and desktop? Old games and new games? WebGL?
arbitrary mouse (or "mouse") button remapping in libinput (my understanding is that libinput itself supports it, but due to some security-related reasons it has to be configured on behalf of the logged-in user and the UI is just not there, or something). the upshot is that I cannot use my trackball the way I'm used to, and that seriously sucks.
HiDPI. It's somewhat unusual for a top end laptop to have 1920x1080 screens these days, and Wayland doesn't support 4k very well. You can upscale, but it looks like garbage, or it has a 2x mode, which draws image and such slightly too large, or you can deal with everything being tiny.
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.
>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.
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?
The idea of using DRM Leasing to allow the full-screen app to exclusively grab the framebuffer for itself has been floated around.
I'm not sure how graceful the alt+tab behavior of this approach would be though.
A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.
That is the problem right? Whenever there is a functionality that you could get with X11 by tweaking configurations files you have to write you own complete new Display Server in Wayland to have that functionality.
This is especially true for people that prefer low latency over tear-free rendering.
I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic. Now, people complain about there being competing Wayland implementations with different feature sets. What's it gonna be, guys?
>I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic
? 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
Those complaints aren't actually opposed but perfectly complement each other.
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 don't think any of those problems can be solved solely in the compositor - they all require co-operation between it and the actual apps. Which means, in practice, that you'd probably have to create an entirely new version of the Wayland API for creating and managing windows, add it to all the compositors, and get all the apps to use it too, on top of all the other work involved in fixing those issues. (This is the only real way to extend the protocol and has already been done a few times - the most recent one I remember was to add the ability to minimize windows.)
HiDPI? Um, what?
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.
Where do we even begin?
Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?
> Windows managers?
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.
I always wonder how people use their linux desktops when they claim that wayland works. Why aren't you using anything like wmctrl, xdotool, xprop, xbindkeys, xterm? Or non-Gnome DE? Don't you need custom keybindings for multiple keyboard layouts with caps/scroll led indication? Don't use wacom devices or anything like it?
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.
It's already usable. I use it every day.
I've been using Wayland as my...whatever it is (display server, window manager, thing) exclusively for the last year or so. I did hit this bug https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1... but it was (eventually) fixed.
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.
A lot of the things that Stack Overflow claims you need X tools for can also be accomplished using sysfs. Without knowing the details of what you're doing I can't give you any specifics.
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.
> Why aren't you using anything like wmctrl, xdotool, xprop, xbindkeys, xterm? Or non-Gnome DE? Don't you need custom keybindings for multiple keyboard layouts with caps/scroll led indication?
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.
I've used Wayland and Gnome ever since they became available in Arch Linux, and I've never needed or missed any of those things. Yes early on there were some annoying bugs but this is life on the bleeding edge ;) These days it all just works.
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 haven't touched any of those tools in a decade or more. I just haven't needed to? The Linux desktop is so much less demanding than it was through the 90s and early 2000s. You don't need to know about any of that stuff to make it work, to customize things, set your favorite key settings (e.g. making Caps Lock useful), to have reasonable hotkeys, etc.
I would argue that not having to use those tools to have a happy working environment makes it further advanced, rather than behind.
>But I think it's a bonus that applications can't listen into keys when they're not in focus.
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.
Then that should be done through a mechanism provided by the desktop environment.
GNOME and I'm pretty sure KDE too has a method to set custom keyboard shortcuts that can execute commands.
> GNOME and I'm pretty sure KDE too
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.
I don't run a desktop environment in X. I run xmonad and terminals. I don't want a desktop environment in wayland, but it seems like that's the only way to get reasonable functionality because it can't be added piecemeal, only monolithically via the compositor.
This is not enough. you fix this use case but there are many others, maybe I want to make a voice/video chat app or a remote desktop app, I will need full control of the display and keyboards not some gimped implementation that is DE specific.
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
> > Windows managers?
> 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...
Sway/wlroots aren't written in Common Lisp, like StumpWM.
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.
Someone has been working on a wlroots-based compositor which is inspired by StumpWM:
https://github.com/sdilts/mahogany
Maybe you're interested in helping?
(Only replying to points that make sense to me)
>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.
Remote operation over the network is actively worked on via Waypipe, seemed to work pretty well for me.
https://gitlab.freedesktop.org/mstoeckl/waypipe/
Universal keybinding and screen capture of any kind. Kind of show stoppers for people who actually use their window manager for managing windows.
I use screen capture and remote operation every day. Are those features planned?
As far as I know not into the wayland protocol itself. The devs have been pretty adamant that wayland is 'just the compositor' and left the rest as an exercise for the community, or the toolkit developers. So for instance there is https://github.com/foss-project/green-recorder but as far as I can tell on wayland it only works for gnome, and requires dbus to work (wat?!).
* Screen recording is a privileged operation in Wayland which is left to compositors to implement as they see fit.
* 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.
The wlroots developers have proposed protocols for screen grabbing etc. which are already supported by some window managers (e.g. Sway) and by some applications.
https://github.com/swaywm/wlr-protocols
I don't use remote operation (as imagined by X11) at all. But I do use non-X11 screen-sharing systems all the time.
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!
And I use remote operations all day every day. As does the entire department with hundreds of people. Don't dismiss other peoples works flows without understanding them.
(I ran Linux + X11 as my sole desktop from 1996-2000. And then on and off again for years in VMs.)
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!
Sorry if I misread your comment and thanks for editing it to make it clearer.
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)?
I'm against baking it in precisely because it's not the right thing. Network transparency in X11 led to a design that didn't scale to meet the needs of the vast majority of users:
"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."
https://superuser.com/a/1217295
Sorry, but a stack overflow answer (that doesn't even seem to be written by you) that give a bad overview over how X11 does it is not an explanation of why it can not be done. Or why it should not be done given that all platforms develop abilities to do exactly what I ask for at some point anyway.
First, I never claimed that the quote was written by me! That's what the quote marks and link are for.
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...
Blub paradox. If you habitually confine yourself to a single computer, remoting never becomes a tool you reach for. NeXT had remoting because it was meant for power users in labs full of closely networked workstations.
Not sure what you're talking about here, Haiku's window system has network transparency, with drawcall-forwarding, even. In fact there is an HTML5-based remote client for it!
That's cool! I didn't know that.
Perhaps people might be interested in porting Haiku's graphics system to Linux to replace X11?
Probably not. The entire reason that the remote-drawing works is that the draw calls are passed through all the way up from the widgets and controls layer; for apps that don't use those (e.g. Qt apps, etc.) it's just a dumber VNC (we could make it less dumb, but, a little starved for time right now.) So then you would be porting the entire Haiku toolkit to Linux ... and at that point why not just use Haiku? We have our own kernel for a reason :)
Screenshots and recordings work fine with Sway and GNOME. I don’t know about other compositors. See https://github.com/swaywm/sway/wiki#taking-screenshots
swaywm supports screenshots and screen capture for sure [0]. I haven't personally done anything with screen capture on sway, but I can definitely confirm that grim works for screenshots.
[0] https://github.com/swaywm/sway/wiki#taking-screenshots
Low latency. Wayland forces you to use a compositor.
And the latency depends on the compositor. I believe Arcan achieved 0 frame compositor latency with Wayland. I think the latest gnome-shell Mutter is there as well.
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.
How is gaming in it? Steam games? 3D accelerated games? Games in wine? Fullscreen games? Different resolutions? Alt tabbing between game and desktop? Old games and new games? WebGL?
arbitrary mouse (or "mouse") button remapping in libinput (my understanding is that libinput itself supports it, but due to some security-related reasons it has to be configured on behalf of the logged-in user and the UI is just not there, or something). the upshot is that I cannot use my trackball the way I'm used to, and that seriously sucks.