Originally posted by Ericg
View Post
Announcement
Collapse
No announcement yet.
The Wayland Situation: Facts About X vs. Wayland
Collapse
X
-
So wayland only needs EGL + that one extension? What about KMS? I'm pretty much a noob, when it comes to technical details but what's the reason why only open source drivers support KMS to begin with? Sounds like it can't get implemented into closed-source driver due to legal issues. So will we every have prop. NVIDIA drivers with KMS?
Comment
-
Little errors
VIII) 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. Which is why no one understands the function that validates the window-tree. REAL (Eg: Not Core X11) Toolkits threw this out the the window a long time ago. No pun intended.V) “Wayland can't do remoting.” Wrong. Wayland should be BETTER than X at remoting, partially do ( --> due to) its asynchronous-by-design nature.VI) “Wayland breaks everyone's desktop.” Also wrong. Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with. There is one known snag and thats with window transformations because an app thinks its in the top right corner of the screen (yay global coordinates) [...]I) “Every frame is perfect.” Wayland's main goal is that no matter how high the system load is,Let the clients handle things(,) they can change - they can break (things all) everything they want because it's THEM who (has) have to deal with the fallout of (that) such a breakage.III) Hardware specific backends. I'm sure some people saw that the Rasberry Pi has got a Wayland specific backend(,) and how it allowed the hardware to be taken advantage of more fully. It wont be necessary for all things(,) as most things WON'T need a hardware-specific backend...but it sure (its) is nice to have it available. It means we have freedom, we have the choice to make specific tweaks if we need to. Or if we realize down the road that the main backend has some architectural flaw in it, we can (change) swap it out with one that doesn't.
@Article: Great work on wrapping it all up that nicely!Last edited by frign; 08 June 2013, 06:38 AM.
Comment
-
What will happen to the several less frequently used X extensions in XWayland?
I'm especially thinking of stuff like Xtest or Xrecord. Will stuff like that still work in XWayland? I imagine that this is not possible, because the X client can't "break out of its virtual X server"?
Also, right now it is possible to - in addition to using Xtest - send custom X events via XSendEvent() to other clients. I guess it will not be possible to send e.g. key events from Xwayland to a real wayland client, right? Or from an XWayland client to another XWayland client?
Asking this because I'm developing Robotux, which is a macro recorder that heavily relies on this functionality.
I think a complete rewrite will be required to get this running on wayland, right?
And then again, will it be possible to inject input events the other way round (i.e. sending events from Wayland to an xWayland client)?
Thanks
Comment
-
Events
Originally posted by b3nn0 View PostWhat will happen to the several less frequently used X extensions in XWayland?
I'm especially thinking of stuff like Xtest or Xrecord. Will stuff like that still work in XWayland? I imagine that this is not possible, because the X client can't "break out of its virtual X server"?
Also, right now it is possible to - in addition to using Xtest - send custom X events via XSendEvent() to other clients. I guess it will not be possible to send e.g. key events from Xwayland to a real wayland client, right? Or from an XWayland client to another XWayland client?
Asking this because I'm developing Robotux, which is a macro recorder that heavily relies on this functionality.
I think a complete rewrite will be required to get this running on wayland, right?
And then again, will it be possible to inject input events the other way round (i.e. sending events from Wayland to an xWayland client)?
Thanks
Comment
-
Originally posted by frign View PostSeems like a case of German English. And before you start attacking me for being an obvious grammar-Nazi: I am German myself and of the opinion that those sent-in articles need some more proof-reading before being published.Last edited by GreatEmerald; 08 June 2013, 06:56 AM.
Comment
-
I'll try to address the remoting issue as clearly as possible. Please correct me if I'm wrong at any point.
1. Saying "please draw this text here" is much more efficient than sending a rendered image of the text. Especially when scrolling.
2. Wayland (compositor)-level remoting can never do anything better than send images. Any optimizations still only work at rendered image level.
3. Having such efficient remoting built-in, thus available with all apps, is a great advantage for a platform.
4. X was originally designed like that, but due to limits ended up sending images.
Thus..
5. The proper course to keep this platform advantage would be to design a remotable protocol usable by modern apps.
6. Wayland people proposed remoting at a toolkit level, and image-level remoting at the Wayland level. As established above, image-level remoting is inefficient, and toolkit-level remoting would forgo the platform advantage, by only enabling efficient remoting for certain apps, not all.
--
This is the core issue.
Comment
Comment