5 ms·

I've been following the X11 vs Wayland story since very close to the beginning and have built and used wayland and weston multiple times over the years. Cutting

by hyperion2010 9y ago

I've been following the X11 vs Wayland story since very close to the beginning and have built and used wayland and weston multiple times over the years. Cutting through all the FUD on both sides, my conclusion is that Wayland was created in the context of some very specific use cases which essentially preclude it from being a general solution that can replace X by itself (it could succeed if there was a single project to reimplement X in a sane way, but leaving it to GKT and QT is NOT a solution by any stretch of the imagination). Nvidia's engagement with linux simply does not cover the use cases that Wayland was created to address. In my view desktop/workstation use cases are not sufficiently covered by Wayland, and that is where nvidia's focus has been. tl;dr Nvidia has no need to play in this space, anyone using X will just use X without the translation layer.

madez 9y ago
While your post is interesting, it is also vague. Can you specify what Wayland is missing that can't be adequately handled by QT or GTK, or do you just have the feeling there is such a thing?
- hyperion2010 9y ago
  Without speaking too much FUD from the X11 side the main issues facing workstation use cases are input handling and permissions. The current wayland party line is "just use dbus to communicate between windows." This is complete madness because it basically means that if you want programs to be able to work together and not steal each others keybinds they all have to depend on a message passing framework. Full disclosure I have done everything in my power to avoid installing dbus and having dbus dependencies, but it is getting harder and harder. That said, it doesn't matter what you think about dbus, it is completely unrealistic to expect that every piece of gui software written for linux to be rewritten to include dbus. This is basically going back to the days of cooperative multitasking and I think we all know how that ended, the overhead is just too high.
  - sjellis 9y ago
    I only follow Linux graphics casually, but AIUI one of the principles of the Wayland initiative was to replace the monolithic model of X with a combination of more tightly scoped components. For example, libinput was created to take responsibility for actually handling input devices, so that Wayland compositors would never need to carry that code, and the input device handling in X could be decommissioned. From that point of view, "Wayland" is kind of a short-hand for a number of different stacks that have some components in common, and speak the Wayland protocol. If you choose not to use a complete stack on a system, then the result can't be fully functional. Personally, I don't have any sense of how much dark matter is in the area of Linux GUI applications. We can easily know about Open Source, where most modern applications sit on toolkits and desktops that are moving to Wayland, but presumably places like CERN have some really old internal applications that will only ever run on X until they are replaced. I'm genuinely unsure how large that problem is. I have to say that I'm always skeptical about arguments that something can't be done for performance reasons. People have been using that argument against new technology since at least the days when C was decried as new-fangled, decadent luxury.
  - wuch 9y ago
    What exactly do you mean by "stealing each other keybindings"? From what you have described so far, it would seem to me that you are describing problem specific to X11 where global keybindings are often implemented in spyware manner, i.e., listening to all keyboard events (regardless of current window focus) and reacting accordingly. They may conflict with each other, they may interfere with each other, they may spy on user, in other words they are not working together at all. There is no standard way to register global keybindings under Wayland yet, but this is bound to happen eventually. Not as a builtin part of Wayland, but it doesn't matter. It will of course use D-Bus interface, as KDE does it now for example - but if an application doesn't support this interface, it can't steal keybindings, it just doesn't get to install global keybindings itself. Not sure what you have exactly against D-Bus, but clearly modern Linux desktop embraced it.
    - gens 9y ago
      I have something against dbus. Bout the protocol and the implementation are very much over-engineered. The protocol at least has an excuse. In the desktop things, that wayland aims to do, dbus is useless. (actually i don't know what it's useful for at all, other then quickly hacking some object oriented (gui)client-server desktop program) I do recommend reading the dbus protocol (the protocol, not the API). Sorry to sound negative but "modern linux" now means "desktop crap", and it is all crap. Freedesktop.org (the linux "desktop" "standards" authority) has gone from "ehh, passable" to "complete crap" in the last... idk 5-10 years (the "desktop" quoting is because it has gone pass the actual desktop problems).
microcolonel 9y ago
> (it could succeed if there was a single project to reimplement X in a sane way, but leaving it to GKT and QT is NOT a solution by any stretch of the imagination). Qt and GTK are not responsible for implementing the compositor at all. Compositors aren't actually the problem at all, the problem is applications. XWayland is one of the main ways we are going to bring legacy applications to Wayland desktops. It works about as well as X does, and lets the other applications take advantage of the sane architecture of Wayland. > In my view desktop/workstation use cases are not sufficiently covered by Wayland, and that is where nvidia's focus has been. What use cases? The only thing that's missing for me is input method integration. It has full display colour management, handles multiple refresh rates in the same session well, handles scaling, supports every input device I own (including graphics tablets). What's not really firm right now is native support in every application, that's coming along at some rate, and XWayland is bridging that gap quite well.
- Brianne88 9y ago
  Irene answered I'm in shock that a mom can make £5437 in a few weeks on the inte _________http://bit.do/dnRs5 http://bit.do/dnRs5
- hyperion2010 9y ago
  Qt and GTK and responsible for implementing how all of their windows talk to each other. My point is that it is not reasonable to expect or require programs to depend on a widget toolkit just so they can get proper keyboard input. I realize this is a bit of an exaggeration, but X11 is more than something that draws windows and from my understanding wayland doesn't address many of the other parts. For example, from my understanding wayland does not provide a standard way to support window manager level keybinds that override the binds set by the developer of the window that currently has focus. For me this means that the primary way I interact with my computer is now broken on wayland unless every single program I use implements the ability to pass those custom keybinds to the program that actually handles them. Sure, everyone can implement their own way of dealing with window manager level keybinds but that completely defeats the purpose of having a standard in the first place. Probably the most salient issue with wayland is that it prevents programs from communicating with each other in the name of 'security' and 'sandboxing' when preventing those things at the display server level adds literally zero security and just makes everything more painful for application developers (imo to the point where they simply won't touch the stuff). If there were a 'windowing protocol' that went along with wayland that covered many of the things wayland does not then I do not think there would be as much of an issue, but the thought that we can force a new display server on people without the other bits as well seems at best naive. Again, I think that the absence of such a 'windowing protocol' from wayland is because one of the main use cases it was developed for often had literally one program running (car backup camera displays). I do not dispute that xwayland bridges the gap. But if people are using X right now then nvidia has no reason to support xwayland right now because there are no wayland only applications that their customers are demanding support for. Down the line that may change, but from a corporate decision making point of view there is zero reason to do this.
ryanmarsh 9y ago
tl;dr it's 2017 and video is still a wasteland on Linux

madez 9y ago

While your post is interesting, it is also vague. Can you specify what Wayland is missing that can't be adequately handled by QT or GTK, or do you just have the feeling there is such a thing?

hyperion2010 9y ago
Without speaking too much FUD from the X11 side the main issues facing workstation use cases are input handling and permissions. The current wayland party line is "just use dbus to communicate between windows." This is complete madness because it basically means that if you want programs to be able to work together and not steal each others keybinds they all have to depend on a message passing framework. Full disclosure I have done everything in my power to avoid installing dbus and having dbus dependencies, but it is getting harder and harder. That said, it doesn't matter what you think about dbus, it is completely unrealistic to expect that every piece of gui software written for linux to be rewritten to include dbus. This is basically going back to the days of cooperative multitasking and I think we all know how that ended, the overhead is just too high.
- sjellis 9y ago
  I only follow Linux graphics casually, but AIUI one of the principles of the Wayland initiative was to replace the monolithic model of X with a combination of more tightly scoped components. For example, libinput was created to take responsibility for actually handling input devices, so that Wayland compositors would never need to carry that code, and the input device handling in X could be decommissioned. From that point of view, "Wayland" is kind of a short-hand for a number of different stacks that have some components in common, and speak the Wayland protocol. If you choose not to use a complete stack on a system, then the result can't be fully functional. Personally, I don't have any sense of how much dark matter is in the area of Linux GUI applications. We can easily know about Open Source, where most modern applications sit on toolkits and desktops that are moving to Wayland, but presumably places like CERN have some really old internal applications that will only ever run on X until they are replaced. I'm genuinely unsure how large that problem is. I have to say that I'm always skeptical about arguments that something can't be done for performance reasons. People have been using that argument against new technology since at least the days when C was decried as new-fangled, decadent luxury.
- wuch 9y ago
  What exactly do you mean by "stealing each other keybindings"? From what you have described so far, it would seem to me that you are describing problem specific to X11 where global keybindings are often implemented in spyware manner, i.e., listening to all keyboard events (regardless of current window focus) and reacting accordingly. They may conflict with each other, they may interfere with each other, they may spy on user, in other words they are not working together at all. There is no standard way to register global keybindings under Wayland yet, but this is bound to happen eventually. Not as a builtin part of Wayland, but it doesn't matter. It will of course use D-Bus interface, as KDE does it now for example - but if an application doesn't support this interface, it can't steal keybindings, it just doesn't get to install global keybindings itself. Not sure what you have exactly against D-Bus, but clearly modern Linux desktop embraced it.
  - gens 9y ago
    I have something against dbus. Bout the protocol and the implementation are very much over-engineered. The protocol at least has an excuse. In the desktop things, that wayland aims to do, dbus is useless. (actually i don't know what it's useful for at all, other then quickly hacking some object oriented (gui)client-server desktop program) I do recommend reading the dbus protocol (the protocol, not the API). Sorry to sound negative but "modern linux" now means "desktop crap", and it is all crap. Freedesktop.org (the linux "desktop" "standards" authority) has gone from "ehh, passable" to "complete crap" in the last... idk 5-10 years (the "desktop" quoting is because it has gone pass the actual desktop problems).

microcolonel 9y ago

> (it could succeed if there was a single project to reimplement X in a sane way, but leaving it to GKT and QT is NOT a solution by any stretch of the imagination). Qt and GTK are not responsible for implementing the compositor at all. Compositors aren't actually the problem at all, the problem is applications. XWayland is one of the main ways we are going to bring legacy applications to Wayland desktops. It works about as well as X does, and lets the other applications take advantage of the sane architecture of Wayland. > In my view desktop/workstation use cases are not sufficiently covered by Wayland, and that is where nvidia's focus has been. What use cases? The only thing that's missing for me is input method integration. It has full display colour management, handles multiple refresh rates in the same session well, handles scaling, supports every input device I own (including graphics tablets). What's not really firm right now is native support in every application, that's coming along at some rate, and XWayland is bridging that gap quite well.

Brianne88 9y ago
Irene answered I'm in shock that a mom can make £5437 in a few weeks on the inte _________http://bit.do/dnRs5 http://bit.do/dnRs5
hyperion2010 9y ago
Qt and GTK and responsible for implementing how all of their windows talk to each other. My point is that it is not reasonable to expect or require programs to depend on a widget toolkit just so they can get proper keyboard input. I realize this is a bit of an exaggeration, but X11 is more than something that draws windows and from my understanding wayland doesn't address many of the other parts. For example, from my understanding wayland does not provide a standard way to support window manager level keybinds that override the binds set by the developer of the window that currently has focus. For me this means that the primary way I interact with my computer is now broken on wayland unless every single program I use implements the ability to pass those custom keybinds to the program that actually handles them. Sure, everyone can implement their own way of dealing with window manager level keybinds but that completely defeats the purpose of having a standard in the first place. Probably the most salient issue with wayland is that it prevents programs from communicating with each other in the name of 'security' and 'sandboxing' when preventing those things at the display server level adds literally zero security and just makes everything more painful for application developers (imo to the point where they simply won't touch the stuff). If there were a 'windowing protocol' that went along with wayland that covered many of the things wayland does not then I do not think there would be as much of an issue, but the thought that we can force a new display server on people without the other bits as well seems at best naive. Again, I think that the absence of such a 'windowing protocol' from wayland is because one of the main use cases it was developed for often had literally one program running (car backup camera displays). I do not dispute that xwayland bridges the gap. But if people are using X right now then nvidia has no reason to support xwayland right now because there are no wayland only applications that their customers are demanding support for. Down the line that may change, but from a corporate decision making point of view there is zero reason to do this.

ryanmarsh 9y ago

tl;dr it's 2017 and video is still a wasteland on Linux