How do you know? I mean this thread is pretty much "yay it's new, so it must be better"
I've read many comments about X being outdated and unmaintainable. But apart from my own experience(the C-Api!) I have yet to see anyone coming up with evidence and or actual knowledge.
So let's play a game:
1. Think about a problem you have with X, anything.
2. Is it an actual X issue or is it a problem with the Kernel, Scheduling or DRM?
3. Is the issue really X or is it another part of the graphic stack, e.g. Mesa, Gallium, the drivers?
4. Is it really a problem within X(the infrastructure, Apis, fundamentals) or is it a simple bug/unfinished feature?
If you still have anything, you may post it here. If not, please stop talking about Wayland as the future
I'll bite. Below are a few problems I encountered the last 2 weeks while programming x directly:
1. X treats the mouse wheel as a button (not an axis), which breaks mouse polling (you will never catch wheel movements this way) and makes wheel acceleration impossible.
2a. This wouldn't be an issue if X was able to deliver mouse messages to more than one window at the same time. Unfortunately, it cannot.
2b. The same for keyboard. At least, XQueryKeymap generally works as expected here (faint praise).
3. Even worse, it only offers absolute mouse events, not relative motions. You can emulate relative motions with XWarpPointer but then you lose absolute motions. These three items are why Wine has never been able to emulate mouse movement correctly during this past decade or so. XInput2 fixes those issues but you cannot rely on users having that installed yet.
4. Xlib is an arcane, ill-designed and essentially undocumented API. Yes, we have a few $120 books and an outdated API reference (tronche) - for what's essentially the foundation for our entire graphical environment!
5. How many times was XInput2 (multi-pointer X) delayed? It was finally delivered in 2010. Note that this is functionality that has been available on Windows since 2001!
6. The GLX protocol has stopped evolving. Each vendor makes undocumented additions (either by design or by mistake), making indirect GL completely unreliable for anything more than spinning gears.
7. The threading model sucks. No wait, there is no threading model. You must serialize each and every access (yes, that 6-core machine you are so proud of? It's useless).
8. XRender. Oh god. Software rendering is more reliable and faster (check the Qt blog).
9. Vsync-ed rendering? Sorry, there's no protocol for that. Check back next decade.
10. The whole API is built around 20 year old concepts (palletes, colormaps, ...) This is not 1990 anymore, modern video hardware doesn't even support palleted modes! But no, XCreateWindow has you interact with that stuff directly.
On the whole, X works, just barely, but it is seriously outdated. Wayland cannot come soon enough.
X has problems, but for most users there are also a decade of workarounds that have hidden them away. For example, few people write native Xlib code unless they're writing a low-level library like Gtk... everyone else just uses those libraries.
Any new user interface that loses the abilitiy to efficiently display the output of a program on a completely different machine or move, open or close windows which have locked up would be a massive step backwards. For that matter, any new Linux distro which doesn't support X output will suddenly be unable to display its applications on a remote machine running other distros, causing serious interoperability issues.
What if X could still be used as legacy and Wayland could serve as a modern replacement untill X12 would come around. I mean with all this new tech, X11 has its shortcommings. Sounds like the protocol needs some serious rethinking?