Yep, the 255 keycode limit does seem to be specific to X (or at least to the current revision of X).
I'll bite. Below are a few problems I encountered the last 2 weeks while programming x directly:
Originally Posted by fabiank22
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.
X11 has xlib.. What wayland has?
I mean.. What library would be used to, for example, port dwm to wayland?
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?
Cairo and Qt are two possibilities but probably not suckless. An interesting idea would be to port p9p libdraw as a suckless general purpose graphics library on wayland.
Originally Posted by tessio
I heared (not verified) that VLC is now working on a remote desktop solution today. It would be interesting to benchmark it against X.org somehow to see if Wayland is a worthy replacement...
Tags for this Thread