27 ms·

Facts about Wayland vs X

161 points by microwise 13y ago

Zenst 13y ago
The part that really sums things up for me was: "XI) “But Eric, if X11 is so terrible why not just make X12 rather than a whole new protocol?” They did, technically anyway: http://www.x.org/wiki/Development/X12 http://www.x.org/wiki/Development/X12 One big problem with keeping it under the “X” umbrella: Anyone who cares about X would have a say in a future version of it. By calling it “Wayland” they avoid that issue. No one cares. Its an unrelated project, they (the developers) can do what THEY want with their future display server, the people who care about X can go to make X12." Which makes much sense. Given X11 has been around for many many years, albiet various revisions. Heck was only earlier today looking at a old book of mine on X11 from 1989 (X11R4) and recall what a curve it was back then. So I can understand the legacy hangover aspect and with that moving to a new design/brandname enabled many short cuts in the paperwork and other programming politics aspects. With that the 25 years is mooted much in this document about how old X is and with that the book I have is a first edition and also around the time which graphics cards started to become available, albiet expensive (recalling a 10k black and white X station by NCR). Not touched coding on wayland (or indeed X for umpteen years) but would be interesting in how they compare and indeed how they also compare to coding in a standard desktop GUI.
- pyre 13y ago
  There was also the transition between implementations (e.g. Xfree86, X.org, etc).
- derleth 13y ago
  It's the Lisp Problem: If you call your new language by the same name as an existing one, even if you add qualifiers (such as Common Lisp or similar), people will think it's exactly the same and that no progress has been made. OTOH, if you make a minor change, but give the result a whole new name (Java vs C++, C# vs Java), people will think the result is meaningfully different and take it as a sign of major progress.
  - vacri 13y ago
    Perl/Perl6 as well.
astine 13y ago
I was sold on Wayland in terms of technology a while ago. Where Wayland is losing people is when is it going to be ready to use? Sure, you can install Wayland now, but there are no applications that target it. Yes, XWayland is meant to solve this problem. But, XWayland is not ready yet (or is it?) and Wayland is still "just around the corner." That may be for legitimate reasons, but it's what the article really should address.
- AhtiK 13y ago
  According to https://live.gnome.org/Wayland https://live.gnome.org/Wayland Gnome 3.12 will be fully ported to Wayland at Spring 2014. Hopefully others will pick up soon as well. I am not sure if "smaller" window managers such as XMonad would benefit but hearing about XMonad being ported to Wayland would be cool.
  - mercurial 13y ago
    Sure, but I assume this would mean Haskell bindings for Wayland first, which as far as I know don't exist yet.
    - Tuna-Fish 13y ago
      In Wayland architecture, the window manager is the display server. To provide wayland-XMonad, you don't need Haskell bindings, you need an implementation of the protocol in Haskell. This isn't as horrible as it sounds, because unlike X, the display server in Wayland is pretty tiny. The current implementation is like ~10k lines. I expect it to fit in sub 3k lines of Haskell. :)
      - wmf 13y ago
        Realistically I would expect people to reuse as much Weston code as they can.
        Tuna-Fish 13y ago
AhtiK 13y ago
Does anyone know how Wayland compares to Quartz used in OS X?
- gue5t 13y ago
  This is a good question. Is there documentation that really explains the Quartz architecture somewhere?
  - m0nastic 13y ago
    The Apple documentation on Quartz 2d is pretty good (although depending on how familiar you are with the rest of the system, you might need to follow some of the links to read about the other parts): https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html#//apple_ref/doc/uid/TP30001066-CH202 https://developer.apple.com/library/mac/#documentation/Graph...
    - randallu 13y ago
      That's more like Cairo though. I don't think Apple have any public documentation on how the window server part of their platforms works.
- thrownaway2424 13y ago
  One of these exists and the other doesn't.
edwintorok 13y ago
There was a nice overview of Wayland here as well: https://lwn.net/Articles/536862&#x2F https://lwn.net/Articles/536862/
dlitz 13y ago
Some more facts about Wayland and client-side window decorations, quoted from here: http://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland http://blog.martin-graesslin.com/blog/2013/02/client-side-wi... - Nothing in Wayland requires them - QtWayland allows Clients to turn them off - KWin as a Wayland compositor will use server side decorations
- jlgreco 13y ago
  > "No aliasing when rotating/wobbling windows" Has anyone ever used those things for more than a single day? I honestly thought the current compositing window managers don't even support that novelty stuff anymore.
  - coldtea 13y ago
    Rotating? That's something very common.
    - hollerith 13y ago
      Rotating an entire display is very common, but that's not what GP is talking about.
  - randallu 13y ago
    In the context that's not the point -- another plus for client-side decorations is that no synchronization is needed between the decorator and client for resizing. Personally I think client-side decorations are far easier to implement reliably and would welcome them becoming default.
  - deleted 13y ago
    [deleted]
  - nitrogen 13y ago
    I use wobbling windows because it makes my interaction with the system seem more transparent. Rigid windows feel unnatural, but wobbly windows let me become absorbed by my task.
jmhain 13y ago
Daniel Stone actually did a talk involving much of the same subject matter called "The Real Story behind Wayland and X". I'd recommend that over this article (which was partially written by the same guy). He's actually a really charismatic speaker. https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44
- themstheones 13y ago
  Thanks that was rather informative. He is quite a dramatic speaker. I'm surprised because 99% of the technical talks you hear have a speaker mumbling away about minutiae hoping enough of the crowd will fall asleep that they can slip out unnoticed.
  - iso8859-1 13y ago
    I don't know what you are listening too, but 99% is misleading. It's quite dependent on the conference. For example, nearly all the presentations on DConf were good. You must be watching something like this: https://www.youtube.com/watch?v=j0fAyL4Xo2k https://www.youtube.com/watch?v=j0fAyL4Xo2k , I guess?
    - themstheones 13y ago
      Wow that's so much worse than any talk I've ever seen. The weird angle and terrible audio aren't helping but the dude needs to stop talking to the screen.
vardump 13y ago
Wayland is a critical technology for Linux desktop community. X11 has been a reliable workhorse, but its time is up - simply too much cruft accumulated over the years that's not even used anymore. Yet all of it needs to be continually supported, adding to complexity. No one uses X11 primitives for drawing apart from bitmap functionality - even repainting dirty regions (expose events) often involves sending over a new bitmap and using X11 to draw it. This is very inefficient. To implement a reasonably fast GUI, X11 has essentially resorted to hacks (extensions). DRI2 (+GLX) is probably the most important of those. AFAIK, it's what almost everything uses for drawing, and does not work over network at all. Yes, modern X11 is local only. If you're on a network, it's back sending those uncompressed bitmaps. Even with all these hacks, X11+DRI2 can't even maintain tearing free display. Well, at least DRI3 should fix tearing... So if none of modern software needs nothing but a bitmap surface to draw on, why implement and maintain anything else? Which leaves us with Wayland criticizers' favorite topic - network transparency (which X11 practically doesn't have either, but unfortunately that does little to stop some loud uninformed people): Remote display software should use low latency video encoding for essentially same user experience as working locally. Preferably hardware accelerated. But even with software, you can encode a frame under 10ms, using for example a subset of h.264. Even if you added network latency, time for one frame network throughput and client display hardware retrace period, you'd still typically end up with a figure well under 50ms. That'd feel essentially local. It'd beat easily X11 over network, VNC, RDP, etc. in latency and thus practical usability. Heck, that'd even beat Xbox 360 or Playstation 3 game display latency when connected to a typical modern TV (70-170ms)! Many TVs do image processing that adds over 50ms of latency before image is actually displayed. (Note that this processing latency has nothing to do with "pixel response time"). Why no one I know of has written remote display software that functions this way is beyond me. Anyone except OnLive and Gaikai, that is... So, let the old X11 horse have its well-earned rest. It's time to move on.
- ZeroGravitas 13y ago
  xpra does the video compression stuff: http://xpra.org/trac/wiki/Enhancements http://xpra.org/trac/wiki/Enhancements
  - 13y ago
VLM 13y ago
I've occasionally wondered as a crazy hack has anyone ever implemented the VNC window system? The API/interface is squirting out a stream as would be seen over the network on VNC? Client has full control? Much as the simplest way to get cross platform cross browser pixel perfect web page rendering is of course a really big imagemap and skip all that large, slow html and css stuff, the simplest way to implement a windowing system might just be a VNC viewer that can render many simultaneous possibly overlapping streams.
- alanctgardner2 13y ago
  I've done basically this (technically RFB is the protocol VNC uses, but whatever). The team I was on makes an auditing tool that records RFB traffic, transcodes it into MPEG video and also does real-time compositing in RFB. Initially it was just static boxes to obscure stuff, but we started doing messaging as well, until eventually we had a library to write arbitrary strings to the screen. I always wanted to extend it to accept user input as well, but that ventured into X territory too much. It's worth pointing out that adding new data to an existing RFB stream with any kind of speed is stupid hard. The server has the ability to send one of about 11 types of message, from simple - a bitmap or RLE - to stupid - hextile and tight are popular. The only way we found was to parse every message, update a frame buffer, then re-encode the updated framebuffer. Not to mention all of the clients and servers have slightly different implementations, so even though you should be able to implement a subset of the spec, you end up implementing the whole spec, plus kludges for every popular client and server. Particularly egregious is Jolly's Fast VNC, which is probably the best Mac VNC client, but it actively rejects servers which are within spec to accommodate one particular server the dev targeted. /rant If you want to see the actual RFB spec: http://www.realvnc.com/docs/rfbproto.pdf http://www.realvnc.com/docs/rfbproto.pdf
shmerl 13y ago
Can anyone clarify please, how is full OpenGL stack supported in Wayland cases? In X there is libglx, while Wayland relies on OpenGL ES. So how for example would some games which need full OpenGL work on Wayland?
- randallu 13y ago
  Wayland/Mesa clients can use EGL to get a full GL context, it's just another attribute when creating the context (like how you select between GL ES1 and GL ES2).
moomin 13y ago
Back in '94, I was doing a dissertation project in CompSci. I asked people who'd done it for advice. The reply was always the same "Don't use Wanda and don't use X." Wanda was a research operating system developed by Cambridge University. X was much the same, but developed at MIT. I'm amazed X has lasted as long as it has.
belorn 13y ago
One key feature of X that Wayland refuses to implement is the concept of remote access. Everything is intended to be local only. For those "strange" users out there who want remote access, the developers replies has so far been to use VNC. Its kind of odd that remote access has been shoved to the side in this age of cloudiness and always connectedness. One would think that there existed better methods to remote access then just copying the image buffer and compress it.
- buster 13y ago
  But really.. as nice as X11 network is, it's mostly just as easy to use vnc, nx, rdp, whatever. If that means a faster, lighter, better displayserver, go ahead, i say.
- jdjb 13y ago
  My understanding is that X can run as a client on top of Wayland and thus you "strange" users can run remote X applications. "One would think that there existed better methods to remote access then just copying the image buffer and compress it." Web applications fit the bill nicely.
- zqfm 13y ago
  As someone who has never used X's remote access, what are its benefits over VNC?
  - sprash 13y ago
    OpenGL commands sent over the network can be executed on the local graphics card via GLX.
    - Someone 13y ago
      And that, for instance, means that your simulation running on a huge CPU cluster that does not even have a GPU can run interactive graphics on your desktop GPU. I am not sure whether that still is a big advantage nowadays, as the typical cluster is fast enough to do OpenGL in software, but 20 years or so ago, this was a big issue, as that huge cluster might have been a 4 CPU, 2 GB, 100 MHz machine, if you were lucky.
toyg 13y ago
My issue with Wayland is that it risks being another KDE 4.0 (or another PulseAudio): the hype-machine was started too early in its development cycle and this is creating expectations that are then frustrated in practice. If you're trying to switch people en masse from such an entrenched technology, you must have a killer app ready from day 1. Is there an app that directly benefits from Wayland so much that it will entice people to switch? I understand this sort of strategy is difficult in the OSS world, where development is mostly done in the open, but there's a difference between developing and evangelising.
- vacri 13y ago
  The problem is that the video system for your computer isn't just a commodity app, it's a huge, interoperative clump of software. It drives the primary interaction device on most computers, and that interaction is a complex beast on every level. If it was something you could hack up in a basement in a couple of months, we'd already have dozens of choices.
- jmhain 13y ago
  Check out this video of what Wayland can do with the Raspberry Pi GPU. People have tried and failed to get the same performance with X. https://www.youtube.com/watch?feature=player_embedded&v=0UkUal_hHx8 https://www.youtube.com/watch?feature=player_embedded&v=0UkU...
  - exDM69 13y ago
    This is a bit misleading because the RPi X drivers aren't very good and the performance is awful. This is not to say that Wayland isn't an improvement, but with the RPi drivers it doesn't take much.
  - tmzt 13y ago
    Is there any reason why that approach wouldn't work on X? I read a few of the articles on it and seems like it could be implemented in X if somebody spent the time writing it.
    - 13y ago
jacob019 13y ago
alright, I'm convinced. Now how long before I can use it on my Debian desktops?
colanderman 13y ago
What a load of bollocks. Let's tear this apart: > Versioning is handled per client, not per bind. So if your app supports one version of a given extension but your toolkit supports another, you can't predict which version of that extension you will get. Easy solution: open multiple connections. Resources can be shared between connections. (You missed the actual problem with X11 here, which is its current limit of 256 clients. But that's easily fixed with an "X12".) > III) Many years ago, someone had an idea “Mechanism, not policy.” What did that mean? It means that X has its own X-Specific drawing API, That's not at all what that means. "Mechanism, not policy" means the X11 core protocol leaves things like window managers and clipboard selection unspecified. (The ICCCM spec takes care of this.) This is sound design. > it is its own toolkit like GTK+ or Qt. Wow, not at all. What do toolkits have to do with drawing primitives? > It defined the low-level things, such as lines, wide-lines, arcs, circles, rudimentary fonts and other 'building block' pieces that are completely useless on their own. Don't like it? Ignore it and use GLX. X11 is extensible for a reason. > Media Coherence. Whats Media Coherence? In its simplest terms... Your browser window? That's a window. Your flash player window on youtube? The flash player itself, displaying the video, is a sub-window. What keeps them in sync? Absolutely nothing. The events are handled separately and right now you just pray that they don't get processed too far apart. WTF? This is exactly what the Sync extension is for. > “Please generate me a config file........Please actually USE this config file.” Why?? Eventually fixed by making the X-server only use a config file for overrides and making it know and have SANE defaults / auto-detection. This is an argument against XFree86, not X11. Nothing about X11 dictates XFree86's strange configuration mechanism. > Who's ever had problems with multiple monitors under Linux? OR ever had to re-setup all of your monitors after a reboot? All X's fault unless you store it in /etc/X11/xorg.conf.d/50-monitors.conf, then it DOES remember it...but you probably had to write that by hand. Again, WTF does this have to do with X? If your distro is broken and doesn't ship with a decent configuration tool, that will be a problem with Wayland too. > The window tree is a complete mess. Under X every input and text box was its own window which was parented by the window above it. Why? Nothing about X11 dictates you must design programs or toolkits like this. Methinks you're confusing "X" with "Athena toolkit". > Its a nitpick, but its also a valid concern... Under X11, the global pixel counter is 15bits. Which means, between all of your displays you can only have 32,768 pixels. Shit, no way to fix that without designing a new windowing system from scratch. > Everything is a window to X, there's no different window types, its just “A window.” THIS is what "mechanism, not policy" means. X11 doesn't care about window types by design. The ICCCM and EWMH specs are where these things are – by design! – defined! There are different window types, and your window manager is aware of them, without adding needless complexity to the core protocol. FINALLY: don't get me wrong, there are things wrong with X. However most of the things mentioned in this article are not in that set.
SimHacker 13y ago
The X-Windows Disaster: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
stass 13y ago
> “X is Network Transparent.” Wrong. Its not. Core X and DRI-1 were network transparent. No one uses either one. Shared-Memory, DRI-2 and DRI-3000 are NOT network transparent, they do NOT work over the network. This is not true. X11 is network transparent, poorly designed toolkits like GTK are not. So essentially they are writing a new graphics server for Gnome/KDE. But those have never been good X11 citizens anyway.
- makomk 13y ago
  Does anyone even use DRI-2 directly, rather than through Mesa/OpenGL (which can, as far as I can tell, fall back to AIGLX even if you're using DRI-2)?

161 points by microwise 13y ago

Zenst 13y ago

The part that really sums things up for me was: "XI) “But Eric, if X11 is so terrible why not just make X12 rather than a whole new protocol?” They did, technically anyway: http://www.x.org/wiki/Development/X12 http://www.x.org/wiki/Development/X12 One big problem with keeping it under the “X” umbrella: Anyone who cares about X would have a say in a future version of it. By calling it “Wayland” they avoid that issue. No one cares. Its an unrelated project, they (the developers) can do what THEY want with their future display server, the people who care about X can go to make X12." Which makes much sense. Given X11 has been around for many many years, albiet various revisions. Heck was only earlier today looking at a old book of mine on X11 from 1989 (X11R4) and recall what a curve it was back then. So I can understand the legacy hangover aspect and with that moving to a new design/brandname enabled many short cuts in the paperwork and other programming politics aspects. With that the 25 years is mooted much in this document about how old X is and with that the book I have is a first edition and also around the time which graphics cards started to become available, albiet expensive (recalling a 10k black and white X station by NCR). Not touched coding on wayland (or indeed X for umpteen years) but would be interesting in how they compare and indeed how they also compare to coding in a standard desktop GUI.

pyre 13y ago
There was also the transition between implementations (e.g. Xfree86, X.org, etc).
derleth 13y ago
It's the Lisp Problem: If you call your new language by the same name as an existing one, even if you add qualifiers (such as Common Lisp or similar), people will think it's exactly the same and that no progress has been made. OTOH, if you make a minor change, but give the result a whole new name (Java vs C++, C# vs Java), people will think the result is meaningfully different and take it as a sign of major progress.
- vacri 13y ago
  Perl/Perl6 as well.

astine 13y ago

I was sold on Wayland in terms of technology a while ago. Where Wayland is losing people is when is it going to be ready to use? Sure, you can install Wayland now, but there are no applications that target it. Yes, XWayland is meant to solve this problem. But, XWayland is not ready yet (or is it?) and Wayland is still "just around the corner." That may be for legitimate reasons, but it's what the article really should address.

AhtiK 13y ago
According to https://live.gnome.org/Wayland https://live.gnome.org/Wayland Gnome 3.12 will be fully ported to Wayland at Spring 2014. Hopefully others will pick up soon as well. I am not sure if "smaller" window managers such as XMonad would benefit but hearing about XMonad being ported to Wayland would be cool.
- mercurial 13y ago
  Sure, but I assume this would mean Haskell bindings for Wayland first, which as far as I know don't exist yet.
  - Tuna-Fish 13y ago
    In Wayland architecture, the window manager is the display server. To provide wayland-XMonad, you don't need Haskell bindings, you need an implementation of the protocol in Haskell. This isn't as horrible as it sounds, because unlike X, the display server in Wayland is pretty tiny. The current implementation is like ~10k lines. I expect it to fit in sub 3k lines of Haskell. :)
    - wmf 13y ago
      Realistically I would expect people to reuse as much Weston code as they can.
      - Tuna-Fish 13y ago

AhtiK 13y ago

Does anyone know how Wayland compares to Quartz used in OS X?

gue5t 13y ago
This is a good question. Is there documentation that really explains the Quartz architecture somewhere?
- m0nastic 13y ago
  The Apple documentation on Quartz 2d is pretty good (although depending on how familiar you are with the rest of the system, you might need to follow some of the links to read about the other parts): https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html#//apple_ref/doc/uid/TP30001066-CH202 https://developer.apple.com/library/mac/#documentation/Graph...
  - randallu 13y ago
    That's more like Cairo though. I don't think Apple have any public documentation on how the window server part of their platforms works.
thrownaway2424 13y ago
One of these exists and the other doesn't.

edwintorok 13y ago

There was a nice overview of Wayland here as well: https://lwn.net/Articles/536862&#x2F https://lwn.net/Articles/536862/

dlitz 13y ago

Some more facts about Wayland and client-side window decorations, quoted from here: http://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland http://blog.martin-graesslin.com/blog/2013/02/client-side-wi... - Nothing in Wayland requires them - QtWayland allows Clients to turn them off - KWin as a Wayland compositor will use server side decorations

jlgreco 13y ago
> "No aliasing when rotating/wobbling windows" Has anyone ever used those things for more than a single day? I honestly thought the current compositing window managers don't even support that novelty stuff anymore.
- coldtea 13y ago
  Rotating? That's something very common.
  - hollerith 13y ago
    Rotating an entire display is very common, but that's not what GP is talking about.
- randallu 13y ago
  In the context that's not the point -- another plus for client-side decorations is that no synchronization is needed between the decorator and client for resizing. Personally I think client-side decorations are far easier to implement reliably and would welcome them becoming default.
- deleted 13y ago
  [deleted]
- nitrogen 13y ago
  I use wobbling windows because it makes my interaction with the system seem more transparent. Rigid windows feel unnatural, but wobbly windows let me become absorbed by my task.

jmhain 13y ago

Daniel Stone actually did a talk involving much of the same subject matter called "The Real Story behind Wayland and X". I'd recommend that over this article (which was partially written by the same guy). He's actually a really charismatic speaker. https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44

themstheones 13y ago
Thanks that was rather informative. He is quite a dramatic speaker. I'm surprised because 99% of the technical talks you hear have a speaker mumbling away about minutiae hoping enough of the crowd will fall asleep that they can slip out unnoticed.
- iso8859-1 13y ago
  I don't know what you are listening too, but 99% is misleading. It's quite dependent on the conference. For example, nearly all the presentations on DConf were good. You must be watching something like this: https://www.youtube.com/watch?v=j0fAyL4Xo2k https://www.youtube.com/watch?v=j0fAyL4Xo2k , I guess?
  - themstheones 13y ago
    Wow that's so much worse than any talk I've ever seen. The weird angle and terrible audio aren't helping but the dude needs to stop talking to the screen.

vardump 13y ago

Wayland is a critical technology for Linux desktop community. X11 has been a reliable workhorse, but its time is up - simply too much cruft accumulated over the years that's not even used anymore. Yet all of it needs to be continually supported, adding to complexity. No one uses X11 primitives for drawing apart from bitmap functionality - even repainting dirty regions (expose events) often involves sending over a new bitmap and using X11 to draw it. This is very inefficient. To implement a reasonably fast GUI, X11 has essentially resorted to hacks (extensions). DRI2 (+GLX) is probably the most important of those. AFAIK, it's what almost everything uses for drawing, and does not work over network at all. Yes, modern X11 is local only. If you're on a network, it's back sending those uncompressed bitmaps. Even with all these hacks, X11+DRI2 can't even maintain tearing free display. Well, at least DRI3 should fix tearing... So if none of modern software needs nothing but a bitmap surface to draw on, why implement and maintain anything else? Which leaves us with Wayland criticizers' favorite topic - network transparency (which X11 practically doesn't have either, but unfortunately that does little to stop some loud uninformed people): Remote display software should use low latency video encoding for essentially same user experience as working locally. Preferably hardware accelerated. But even with software, you can encode a frame under 10ms, using for example a subset of h.264. Even if you added network latency, time for one frame network throughput and client display hardware retrace period, you'd still typically end up with a figure well under 50ms. That'd feel essentially local. It'd beat easily X11 over network, VNC, RDP, etc. in latency and thus practical usability. Heck, that'd even beat Xbox 360 or Playstation 3 game display latency when connected to a typical modern TV (70-170ms)! Many TVs do image processing that adds over 50ms of latency before image is actually displayed. (Note that this processing latency has nothing to do with "pixel response time"). Why no one I know of has written remote display software that functions this way is beyond me. Anyone except OnLive and Gaikai, that is... So, let the old X11 horse have its well-earned rest. It's time to move on.

ZeroGravitas 13y ago
xpra does the video compression stuff: http://xpra.org/trac/wiki/Enhancements http://xpra.org/trac/wiki/Enhancements
- 13y ago

VLM 13y ago

I've occasionally wondered as a crazy hack has anyone ever implemented the VNC window system? The API/interface is squirting out a stream as would be seen over the network on VNC? Client has full control? Much as the simplest way to get cross platform cross browser pixel perfect web page rendering is of course a really big imagemap and skip all that large, slow html and css stuff, the simplest way to implement a windowing system might just be a VNC viewer that can render many simultaneous possibly overlapping streams.

alanctgardner2 13y ago
I've done basically this (technically RFB is the protocol VNC uses, but whatever). The team I was on makes an auditing tool that records RFB traffic, transcodes it into MPEG video and also does real-time compositing in RFB. Initially it was just static boxes to obscure stuff, but we started doing messaging as well, until eventually we had a library to write arbitrary strings to the screen. I always wanted to extend it to accept user input as well, but that ventured into X territory too much. It's worth pointing out that adding new data to an existing RFB stream with any kind of speed is stupid hard. The server has the ability to send one of about 11 types of message, from simple - a bitmap or RLE - to stupid - hextile and tight are popular. The only way we found was to parse every message, update a frame buffer, then re-encode the updated framebuffer. Not to mention all of the clients and servers have slightly different implementations, so even though you should be able to implement a subset of the spec, you end up implementing the whole spec, plus kludges for every popular client and server. Particularly egregious is Jolly's Fast VNC, which is probably the best Mac VNC client, but it actively rejects servers which are within spec to accommodate one particular server the dev targeted. /rant If you want to see the actual RFB spec: http://www.realvnc.com/docs/rfbproto.pdf http://www.realvnc.com/docs/rfbproto.pdf

shmerl 13y ago

Can anyone clarify please, how is full OpenGL stack supported in Wayland cases? In X there is libglx, while Wayland relies on OpenGL ES. So how for example would some games which need full OpenGL work on Wayland?

randallu 13y ago
Wayland/Mesa clients can use EGL to get a full GL context, it's just another attribute when creating the context (like how you select between GL ES1 and GL ES2).

moomin 13y ago

Back in '94, I was doing a dissertation project in CompSci. I asked people who'd done it for advice. The reply was always the same "Don't use Wanda and don't use X." Wanda was a research operating system developed by Cambridge University. X was much the same, but developed at MIT. I'm amazed X has lasted as long as it has.

belorn 13y ago

One key feature of X that Wayland refuses to implement is the concept of remote access. Everything is intended to be local only. For those "strange" users out there who want remote access, the developers replies has so far been to use VNC. Its kind of odd that remote access has been shoved to the side in this age of cloudiness and always connectedness. One would think that there existed better methods to remote access then just copying the image buffer and compress it.

buster 13y ago
But really.. as nice as X11 network is, it's mostly just as easy to use vnc, nx, rdp, whatever. If that means a faster, lighter, better displayserver, go ahead, i say.
jdjb 13y ago
My understanding is that X can run as a client on top of Wayland and thus you "strange" users can run remote X applications. "One would think that there existed better methods to remote access then just copying the image buffer and compress it." Web applications fit the bill nicely.
zqfm 13y ago
As someone who has never used X's remote access, what are its benefits over VNC?
- sprash 13y ago
  OpenGL commands sent over the network can be executed on the local graphics card via GLX.
  - Someone 13y ago
    And that, for instance, means that your simulation running on a huge CPU cluster that does not even have a GPU can run interactive graphics on your desktop GPU. I am not sure whether that still is a big advantage nowadays, as the typical cluster is fast enough to do OpenGL in software, but 20 years or so ago, this was a big issue, as that huge cluster might have been a 4 CPU, 2 GB, 100 MHz machine, if you were lucky.

toyg 13y ago

My issue with Wayland is that it risks being another KDE 4.0 (or another PulseAudio): the hype-machine was started too early in its development cycle and this is creating expectations that are then frustrated in practice. If you're trying to switch people en masse from such an entrenched technology, you must have a killer app ready from day 1. Is there an app that directly benefits from Wayland so much that it will entice people to switch? I understand this sort of strategy is difficult in the OSS world, where development is mostly done in the open, but there's a difference between developing and evangelising.

vacri 13y ago
The problem is that the video system for your computer isn't just a commodity app, it's a huge, interoperative clump of software. It drives the primary interaction device on most computers, and that interaction is a complex beast on every level. If it was something you could hack up in a basement in a couple of months, we'd already have dozens of choices.
jmhain 13y ago
Check out this video of what Wayland can do with the Raspberry Pi GPU. People have tried and failed to get the same performance with X. https://www.youtube.com/watch?feature=player_embedded&v=0UkUal_hHx8 https://www.youtube.com/watch?feature=player_embedded&v=0UkU...
- exDM69 13y ago
  This is a bit misleading because the RPi X drivers aren't very good and the performance is awful. This is not to say that Wayland isn't an improvement, but with the RPi drivers it doesn't take much.
- tmzt 13y ago
  Is there any reason why that approach wouldn't work on X? I read a few of the articles on it and seems like it could be implemented in X if somebody spent the time writing it.
  - 13y ago

jacob019 13y ago

alright, I'm convinced. Now how long before I can use it on my Debian desktops?

colanderman 13y ago

What a load of bollocks. Let's tear this apart: > Versioning is handled per client, not per bind. So if your app supports one version of a given extension but your toolkit supports another, you can't predict which version of that extension you will get. Easy solution: open multiple connections. Resources can be shared between connections. (You missed the actual problem with X11 here, which is its current limit of 256 clients. But that's easily fixed with an "X12".) > III) Many years ago, someone had an idea “Mechanism, not policy.” What did that mean? It means that X has its own X-Specific drawing API, That's not at all what that means. "Mechanism, not policy" means the X11 core protocol leaves things like window managers and clipboard selection unspecified. (The ICCCM spec takes care of this.) This is sound design. > it is its own toolkit like GTK+ or Qt. Wow, not at all. What do toolkits have to do with drawing primitives? > It defined the low-level things, such as lines, wide-lines, arcs, circles, rudimentary fonts and other 'building block' pieces that are completely useless on their own. Don't like it? Ignore it and use GLX. X11 is extensible for a reason. > Media Coherence. Whats Media Coherence? In its simplest terms... Your browser window? That's a window. Your flash player window on youtube? The flash player itself, displaying the video, is a sub-window. What keeps them in sync? Absolutely nothing. The events are handled separately and right now you just pray that they don't get processed too far apart. WTF? This is exactly what the Sync extension is for. > “Please generate me a config file........Please actually USE this config file.” Why?? Eventually fixed by making the X-server only use a config file for overrides and making it know and have SANE defaults / auto-detection. This is an argument against XFree86, not X11. Nothing about X11 dictates XFree86's strange configuration mechanism. > Who's ever had problems with multiple monitors under Linux? OR ever had to re-setup all of your monitors after a reboot? All X's fault unless you store it in /etc/X11/xorg.conf.d/50-monitors.conf, then it DOES remember it...but you probably had to write that by hand. Again, WTF does this have to do with X? If your distro is broken and doesn't ship with a decent configuration tool, that will be a problem with Wayland too. > The window tree is a complete mess. Under X every input and text box was its own window which was parented by the window above it. Why? Nothing about X11 dictates you must design programs or toolkits like this. Methinks you're confusing "X" with "Athena toolkit". > Its a nitpick, but its also a valid concern... Under X11, the global pixel counter is 15bits. Which means, between all of your displays you can only have 32,768 pixels. Shit, no way to fix that without designing a new windowing system from scratch. > Everything is a window to X, there's no different window types, its just “A window.” THIS is what "mechanism, not policy" means. X11 doesn't care about window types by design. The ICCCM and EWMH specs are where these things are – by design! – defined! There are different window types, and your window manager is aware of them, without adding needless complexity to the core protocol. FINALLY: don't get me wrong, there are things wrong with X. However most of the things mentioned in this article are not in that set.

SimHacker 13y ago

The X-Windows Disaster: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

stass 13y ago

> “X is Network Transparent.” Wrong. Its not. Core X and DRI-1 were network transparent. No one uses either one. Shared-Memory, DRI-2 and DRI-3000 are NOT network transparent, they do NOT work over the network. This is not true. X11 is network transparent, poorly designed toolkits like GTK are not. So essentially they are writing a new graphics server for Gnome/KDE. But those have never been good X11 citizens anyway.

makomk 13y ago
Does anyone even use DRI-2 directly, rather than through Mesa/OpenGL (which can, as far as I can tell, fall back to AIGLX even if you're using DRI-2)?