9 ms·

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 tha

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?

cmm 7y ago
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.
hyperion2010 7y ago
Universal keybinding and screen capture of any kind. Kind of show stoppers for people who actually use their window manager for managing windows.
- whatshisface 7y ago
  I use screen capture and remote operation every day. Are those features planned?
  - hyperion2010 7y ago
    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 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?!).
    - Spivak 7y ago
      * 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.
    - majewsky 7y ago
      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 https://github.com/swaywm/wlr-protocols
  - maxharris 7y ago
    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!
    - petschge 7y ago
      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.
      - maxharris 7y ago
        (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!
        petschge 7y ago
        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)?
        maxharris 7y ago
        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 https://superuser.com/a/1217295
  - snazz 7y ago
    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 https://github.com/swaywm/sway/wiki#taking-screenshots
  - sq_ 7y ago
    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 https://github.com/swaywm/sway/wiki#taking-screenshots
okasaki 7y ago
Where do we even begin? Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?
- PlutoIsAPlanet 7y ago
  > 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.
  - zzzcpan 7y ago
    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.
    - PlutoIsAPlanet 7y ago
      It's already usable. I use it every day.
    - ForHackernews 7y ago
      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/1754693 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.
kaendfinger 7y ago
Remote operation over the network is actively worked on via Waypipe, seemed to work pretty well for me. https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/
mrob 7y ago
Low latency. Wayland forces you to use a compositor.
- zlynx 7y ago
  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.
nwallin 7y ago
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.
- voldacar 7y ago
  >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?
  - pantalaimon 7y ago
    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.
- emersion 7y ago
  A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.
  - sprash 7y ago
    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.
Aardwolf 7y ago
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?

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?

cmm 7y ago

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.

hyperion2010 7y ago

Universal keybinding and screen capture of any kind. Kind of show stoppers for people who actually use their window manager for managing windows.

whatshisface 7y ago
I use screen capture and remote operation every day. Are those features planned?
- hyperion2010 7y ago
  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 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?!).
  - Spivak 7y ago
    * 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.
  - majewsky 7y ago
    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 https://github.com/swaywm/wlr-protocols
- maxharris 7y ago
  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!
  - petschge 7y ago
    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.
    - maxharris 7y ago
      (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!
      - petschge 7y ago
        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)?
        maxharris 7y ago
        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 https://superuser.com/a/1217295
- snazz 7y ago
  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 https://github.com/swaywm/sway/wiki#taking-screenshots
- sq_ 7y ago
  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 https://github.com/swaywm/sway/wiki#taking-screenshots

okasaki 7y ago

Where do we even begin? Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?

PlutoIsAPlanet 7y ago
> 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.
- zzzcpan 7y ago
  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.
  - PlutoIsAPlanet 7y ago
    It's already usable. I use it every day.
  - ForHackernews 7y ago
    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/1754693 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.

kaendfinger 7y ago

Remote operation over the network is actively worked on via Waypipe, seemed to work pretty well for me. https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/

mrob 7y ago

Low latency. Wayland forces you to use a compositor.

zlynx 7y ago
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.

nwallin 7y ago

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.

voldacar 7y ago
>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?
- pantalaimon 7y ago
  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.
emersion 7y ago
A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.
- sprash 7y ago
  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.

Aardwolf 7y ago

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?