3 ms·

Its very doubtful that Wayland will happen in 2016. I'm not sure it does anything to solve real GNU/Linux problems for consumer and/or workstation devices. At

Its very doubtful that Wayland will happen in 2016. I'm not sure it does anything to solve real GNU/Linux problems for consumer and/or workstation devices. At least not without breaking everything else far more. The idea to let all applications render all their pixels without any further system integration is just completely insane when you see the future of GUI computing and interactions. Work on higher/sideway layers should be absolute priority, and X should be considered good enough until then (at least when you are not maintaining it, but that is a completely different story).

shmerl 11y ago
It can happen in 2016. KDE is almost ready, and even Nvidia is approaching releasing their KMS/DRM driver with EGL support. So pieces to at least being able to use Wayland will be in place. However as you say, stuff might be still broken for some use cases, so those will have to be fixed going forward. Wayland doesn't dictate how compositors approach desktop integration. For instance there can be client side or server side decorations and so on.
- xorblurb 11y ago
  Yes, Wayland doesn't dictate anything, and that's the problem! It is the moral equivalent of a glorified framebuffer. Number of subjects relevant in today interfaces interactions? I'm not sure there are any. Meanwhile graphic/interaction stacks on other systems concentrate on what is really needed by advances in tech and usages like HighDPI / mixed DPI / responsive GUI while updating their existing tech (e.g. RemoteDesktop) instead of deprecating them. What does Wayland provides in term of modern usages with modern tech? Maybe I missed something but from what I read it is just backward-incompatible (for apps) low level tech, and for actual users this kind of stuff often have negative value...
  - shmerl 11y ago
    > What does Wayland provides in term of modern usages with modern tech? More direct and simpler (and therefore efficient) way to deal with drawing. X is bloated with tons of overhead and obsolete legacy stuff. Here is a good talk about it: (The Real Story Behind Wayland and X) https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44
    - xorblurb 11y ago
      Very interesting. I'm glad they were sufficiently pushed to eventually start thinking about remoting. I get that X protocol was not that good -- but I'm still not convinced that their model is, not even talking about future proof, suitable for present needs; you have to at least provision for multi-dpi, touch and changing form-factors; you also have to provision for multi-gpu more seriously (his answer: client pb and very difficult) and multimedia (sound synchro, ideally including in remoting cases). I'm also not 100% convinced that the argument that gedit round-trips too much is a good one. You have to rewrite toolkit to use Wayland anyway, so why not comparing that approach to a mere cleanup of the way they use X? And to finish, you will still need quasi perfect retro-compatibility with X for lots of users. So if eventually all of that is handled properly, why not, and given how he said they orient the protocol descriptively more than imperatively this is possible that this can be added in a second time without falling again in X situation full of workarounds, but even in this best case scenario it will still be very late to the party, especially if they feel so much in the mood of stuffs like touchpad driver rewrite (why is that not in a common lower layer anyway?...). And even then, this will only go as far as the client who render every pixel will be able to do anyway... I get that this is more or less what is largely already done anyway by some software, but guess what else is also done today? Using X... so not a really good reason when you are already breaking everything anyway. And also guess what a really efficient remote protocol focused on bitmaps would intrinsically be kind of equivalent to for a lot of use cases? Describing transformation operations on previous images already known by the server. There are tons of operations which today exists and that are reimplemented in web browsers as hacks of e.g. javascript and tilled jpegs; either future "display" stacks are powerful enough to model them efficiently, or we abandon all hopes and the native graphic stack should just be a glorified frame buffer and the real UI should be implemented in a browser -- after all, that's also what is partly already done!

shmerl 11y ago

It can happen in 2016. KDE is almost ready, and even Nvidia is approaching releasing their KMS/DRM driver with EGL support. So pieces to at least being able to use Wayland will be in place. However as you say, stuff might be still broken for some use cases, so those will have to be fixed going forward. Wayland doesn't dictate how compositors approach desktop integration. For instance there can be client side or server side decorations and so on.

xorblurb 11y ago
Yes, Wayland doesn't dictate anything, and that's the problem! It is the moral equivalent of a glorified framebuffer. Number of subjects relevant in today interfaces interactions? I'm not sure there are any. Meanwhile graphic/interaction stacks on other systems concentrate on what is really needed by advances in tech and usages like HighDPI / mixed DPI / responsive GUI while updating their existing tech (e.g. RemoteDesktop) instead of deprecating them. What does Wayland provides in term of modern usages with modern tech? Maybe I missed something but from what I read it is just backward-incompatible (for apps) low level tech, and for actual users this kind of stuff often have negative value...
- shmerl 11y ago
  > What does Wayland provides in term of modern usages with modern tech? More direct and simpler (and therefore efficient) way to deal with drawing. X is bloated with tons of overhead and obsolete legacy stuff. Here is a good talk about it: (The Real Story Behind Wayland and X) https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44
  - xorblurb 11y ago
    Very interesting. I'm glad they were sufficiently pushed to eventually start thinking about remoting. I get that X protocol was not that good -- but I'm still not convinced that their model is, not even talking about future proof, suitable for present needs; you have to at least provision for multi-dpi, touch and changing form-factors; you also have to provision for multi-gpu more seriously (his answer: client pb and very difficult) and multimedia (sound synchro, ideally including in remoting cases). I'm also not 100% convinced that the argument that gedit round-trips too much is a good one. You have to rewrite toolkit to use Wayland anyway, so why not comparing that approach to a mere cleanup of the way they use X? And to finish, you will still need quasi perfect retro-compatibility with X for lots of users. So if eventually all of that is handled properly, why not, and given how he said they orient the protocol descriptively more than imperatively this is possible that this can be added in a second time without falling again in X situation full of workarounds, but even in this best case scenario it will still be very late to the party, especially if they feel so much in the mood of stuffs like touchpad driver rewrite (why is that not in a common lower layer anyway?...). And even then, this will only go as far as the client who render every pixel will be able to do anyway... I get that this is more or less what is largely already done anyway by some software, but guess what else is also done today? Using X... so not a really good reason when you are already breaking everything anyway. And also guess what a really efficient remote protocol focused on bitmaps would intrinsically be kind of equivalent to for a lot of use cases? Describing transformation operations on previous images already known by the server. There are tons of operations which today exists and that are reimplemented in web browsers as hacks of e.g. javascript and tilled jpegs; either future "display" stacks are powerful enough to model them efficiently, or we abandon all hopes and the native graphic stack should just be a glorified frame buffer and the real UI should be implemented in a browser -- after all, that's also what is partly already done!