Announcement

Collapse
No announcement yet.

Dual X Servers Running Side-By-Side With Wayland

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Dual X Servers Running Side-By-Side With Wayland

    Dual X Servers Running Side-By-Side With Wayland

    Phoronix: Dual X Servers Running Side-By-Side With Waylandhttp://www.phoronix.com/vr.php?view=NjkyMg

  • elanthis
    replied
    Originally posted by drag View Post
    The only thing I don't like about Wayland is the "oh we'll support X through composited interface, but toolkits like GTK can be ported to support it natively".
    GTK already supports 5 or 6 backends. It's intended to be portable. Same with any other toolkit. Wayland won't require any extra layers at all. If anything, Wayland essentially removes from the graphics stack the layers that exist within X today.

    If -- and that's a big "if" -- Wayland's model is determined to truly be the successor to X, then it's really just a matter of adding a new backend to a toolkit that already has half a dozen.

    If GTK was to get popular on Wayland then that means that unless new features are supported both in X and in Wayland then that means that GTK won't be able to benefit easily from improvements in either one.
    See, though, the entire reason Wayland works the way it does is because real applications don't need additional features in EITHER backend. The future that we're approaching is one in which all rendering is done via OpenGL (usually through a higher-level toolkit/library interface), in which X subwindows are unused, in which DBUS facilitates all high-level desktop app communication, and in which all X really does is provide the basic window stacking/management features on top of the in-kernel or library-ified graphics and input components. That's why Wayland is so simple. Nobody really needs the features the Wayland design lacks. All modern applications need from the windowing system are windows, direct rendering, compositing, input, and a few other basics.

    Almost all interesting features -- including allowing apps to move between X servers like you just asked for, as well as networking -- are really toolkit problems and library problems. A modern toolkit's abstraction layer needs very little outside of a way of getting hold of an OpenGL context, getting input events, and low-level stuff like threading and I/O and basic audio. Current toolkits have bigger abstraction layers mostly just because they were designed in the day and age when the X drawing API or Windows' GDI API were actually considered useful.

    Leave a comment:


  • drag
    replied
    Well I like the remote features of X. I think it's very cool.

    There are things that could make it very more cooler.. like the ability to detatch and re-attach clients to other X servers and stuff. You can do that with Sun's X terminals, for example. Also with Windows you can attatch remotely using rdesktop and get access to the apps from your last session. Also with Vista if the display/graphics drivers crash for whatever reason the system resets the graphics and you don't loose your session either.

    I mean I use remote X every day. I like that feature, I don't care much about X either way. If the protocol can be updated or replaced to make things simplier then that would be wonderful.

    .
    Things are not fast and wonderful right now? I don't see X apps being outperformed by their Windows counterparts and we're able to do Vista-like stuff with 20+ year old technology? It seems be doing pretty well IMHO.
    Well I didn't mean it like 'fast' as in raw performance, but of maintainability and whatnot. 'Fast' as in the ability to get things done in a timely manner and having good fast performance. (X isn't wonderful right now, though. )

    There are only so many hackers out there with the capabilities of working with X and graphics. If simplifying things means getting rid of X completely and that means easier times for developers.. then I support it.

    --------------------------

    The only thing I don't like about Wayland is the "oh we'll support X through composited interface, but toolkits like GTK can be ported to support it natively".

    This is the sort of 'multiple backend' thing that plagues Linux sound stuff. Like "Oh, if Alsa doesn't work use OSS" type things.. or Amarok supporting a dozen different audio APIs. It's a mess and each 'choice' brings with it's own advantages and broken functionality. Confusing and difficult and time consuming.

    The problem is that in order to get that extra layer of abstraction too support two sorts of backends like X vs Wayland means a lot of extra work. Plus unless you can get functionality effectively the same on both systems then that means that your going to get stuck with the lowest common denominator.. If GTK was to get popular on Wayland then that means that unless new features are supported both in X and in Wayland then that means that GTK won't be able to benefit easily from improvements in either one. It'll get stuck in between them and only using functionality that is present in both environment.

    So if your going to create a alternative you need to make sure that alternative has the capabilities of replacing X completely. Sure keep a X server around for compatibility with legacy applications and whatnot, but make Wayland nice enough and with the required functionality that people need from a GUI system so all future developments happen on that system.

    Something like that.

    Needless layers of abstraction really hurt Linux and makes things more difficult. So either work on replacement of X completely (or a updated XR12 protocol) and hope it takes off, or encourage people never to program in Wayland directly except for special purposes and just use it for managing the display. Something, to avoid the division.

    Leave a comment:


  • Ex-Cyber
    replied
    Originally posted by drag
    I mean remote X isn't something that is critical for desktops. Never was. So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.
    People who have lurked in the Unix/Linux scene long enough to have seen this argument a dozen times will take this statement to mean that you don't support getting rid of remote X (even if that is denying the antecedent ).

    Leave a comment:


  • quintesse
    replied
    Originally posted by drag View Post
    I mean remote X isn't something that is critical for desktops. Never was.
    Uhm, you probably weren't alive yet or too young to remember the time of the dumb and thin terminals? When I started studying things were all done remotely. The idea that some time you would have multiples of that power in your mobile phone was pure science fiction

    Originally posted by drag View Post
    So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.
    Things are not fast and wonderful right now? I don't see X apps being outperformed by their Windows counterparts and we're able to do Vista-like stuff with 20+ year old technology? It seems be doing pretty well IMHO.

    That doesn't mean I don't think we should take a look at bringing all of this technology into the new millennium, but lets not throw out the baby with the bath water.

    Leave a comment:


  • drag
    replied
    I donno.

    I mean remote X isn't something that is critical for desktops. Never was. So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.

    I like X network functionality. I don't give two squats about the actual nature of the protocol itself, though.

    But one thing to consider is that from X's original conception in 1983-ish to 1987 there were 11 different versions of the X protocol. We have been using version 11 for 21 years now. One of the big reasons (according to wikipedia) for the change from X10 to X11 was to make it more 'hardware independent'.

    Also there is functionality present in competitors... like with Vista your able to have disconnect between the applications and the display. If you log into rdesktop, for example, you can view and interact with whatever application you had left open on your last session.

    Also with Vista if your display crashes from buggy drivers (or whatnot) then the display will go to black, Vista will attempt to restart the graphics stuff, and then if it works you can log back into your previous session. For lots of users if their display drivers crap out then all they see is a brief black screen.

    So it would be nice to have that same sort of functionality for Linux.

    Leave a comment:


  • drag
    replied
    In the face of networked apps -- and even to a lesser extent all apps -- it is generally better to either render _everything_ in the hardware or to render everything in software. Otherwise you have to copy buffers back and forth, and that slaughters performance in oh so many ways.
    Well at least Gnome stuff is much better now then the time period I was talking about then.

    I had a discussion once about gnome-terminal vs xterm and performance and people were telling me that xterm would provide better or more consistent performance then gnome-terminal because it was closer to the x protocol or something like that. Less gtk bullshit getting in the way or whatever. I did benchmarks and gnome was obviously using tricks with text rendering for remote X apps and whatnot and gnome-terminal easily trounced xterm. Wasn't even a comparison.

    Like I mentioned up there it's my current experience (running Fedora 10 on my laptop) that running a Xephyr-based nested X server with gnome-session (from a CentOS 5.2 system) over AES128-encrypted SSH tunnel over 100Mb/s connection is able to provide a much better 'feel' and responsive interface then Rdesktop running over "localhost" (well not loop-back, but over virtual network) to a Windows VM.

    This is a KVM-based Windows VM that was created and managed using Fedora's virt-manager stuff.

    In turn I am using Rdesktop becuase it performed much better at bigger sizes then the VNC stuff that is provided by default by virt-manager to handle graphical consoles.

    And KVM and the virtual network is no slouch either, mind you.


    It may or may not be worth your time to do what I am suggesting. Or it may be something that other people need to do.

    But I figure with lessons learned with NX and whatever the GTK/Gnome guys are doing, plus the lack of usefulness for the majority of functionality that X protocol provides then maybe it's just time for a new, much streamlined X protocol.



    How so? If you're talking about requiring root access, that's caused by the driver model. X on Wayland would not require root access, nor would X with an update DDX/kernel interface.
    I am talking about X as the network protocol. If you run X outside of a ssh tunnel then it can easily get sniffed. It's a chronic issue and if you every tried to run a nested X server without the '-ac' switch to disable the access controls then its very difficult to get working.

    If like you guys said that X protocol requires a lot of extra horseshit that nobody uses anymore then it's probably time to update the X protocol. Maybe make it X12 or something.

    It's been done in the past, obviously.

    "legacy free" and "backwards compatible" are two entirely contradicting terms.
    Ya read it wrong. Legacy xfree-style X server. As in X11R6 compatible. Which is what we all use now.

    'legacy xfree'-style server

    X is very crusty and one of the big things is backwards compatibility. So you just shovel that off to the side and modern apps would use the (currently imaginary) X12 protocol that (my imaginary) Wayland-style system would support natively.
    Last edited by drag; 12-15-2008, 04:39 PM.

    Leave a comment:


  • elanthis
    replied
    I also noticed that with Opengl applications and AIGLX I could play full screen (like 1280x960 or so) Return to Castle Wolfenstien over (my faster home network) 100Mb/s connection, even with ssh encryption. Like 20-40fps. Blender worked and all that. This was a while ago when AIGLX first came out. Over the same connection Gnome and KDE apps had more noticable lag.

    If like your saying that X apps are barely using X aymore, or at least using it less and less, then it may be a good time to redesign X protocol to make it easier to compress and avoid the ping-pong type client-server behavior that causes lots of performance issues over higher latency connections.
    The lag in KDE/GNOME apps can be from a combination of things; usually not the protocol itself. Certain toolkit rendering engines try to hardware accelerate everything they can but then fallback on software rendering for things they can't -- so you end up having to copy buffers back and forth over the network (not to mention hardware buses) multiple times to render things. The roundtrips are also not really the protocol's fault. The xlib library requires a lot of technically unnecessary roundtrips, for which xcb was created to fix (no need for a protocol change). Some themes or widgets also just do relatively dumb things with rendering, such ss trying to grab copies of buffers for things that could be done in a copy-free manner (especially on modern hardware w/ shaders).

    In the face of networked apps -- and even to a lesser extent all apps -- it is generally better to either render _everything_ in the hardware or to render everything in software. Otherwise you have to copy buffers back and forth, and that slaughters performance in oh so many ways.

    The security of X is one huge thing that is holding it back also. This is something that could be addressed. Especially when you move X completely off the hardware.
    How so? If you're talking about requiring root access, that's caused by the driver model. X on Wayland would not require root access, nor would X with an update DDX/kernel interface.

    If you mean controlling which apps can talk to other apps with the protocol, I believe that's what XACE is supposed to tackle. I have to yet to evne find a specification for XACE online, though, so I'm unsure...

    Then people could keep the 'legacy xfree'-style server for backwards compatibility with older protocols.
    "legacy free" and "backwards compatible" are two entirely contradicting terms.

    Leave a comment:


  • drag
    replied
    Well then I wouldn't consider it a 'replacement' for X so much. That implies replicated functionality. A 'alternative' to X would probably be more accurate.

    At least that's how I got about defining terms when I talk to people about replacing Exchange servers or other such things. Like I can say that: "Linux can offer lots of alternatives to using Exchange, but right now it offers no real replacement for it.. but Openchange (not to be confused with openexchange) is in the works so that you can eventually use a Linux server to provide a drop in replacement."

    That sort of thing. It's a bit nitpicky, I know.

    But I think people would be more interested in it as a completely new graphics system for Linux as opposed to a 'just a new X server'. We already have lots and lots of different X Servers.


    -----------------------------------------------



    Hell, in light of what you guys were talking about it may be time for a entire new X Windows protocol. Something that's updated.

    The network functionality of X is much to valuable to leave it up to 'use vnc' or stuff like that. X is a much better performer nowadays over the network then it used to be. Just look at LTSP. And it would suck to force toolkit makers to support multiple backends to get the benefits of Wayland without sacrificing good thin client support.

    For example I'll setup a 1024x768 Xephyr display to run remote Gnome Desktop over encrypted SSH tunnel. This thing is _snappy_. It's a much better performer over (a rather slow, lossy, and overgrown corporate network, from one building to another) 100Mb/s ethernet connect then Rdesktop is able to do over localhost to Windows running on a VM. (with Rdesktop itself performing much better then the VNC-based terminal that I get with Fedora's virt-manager)

    I also noticed that with Opengl applications and AIGLX I could play full screen (like 1280x960 or so) Return to Castle Wolfenstien over (my faster home network) 100Mb/s connection, even with ssh encryption. Like 20-40fps. Blender worked and all that. This was a while ago when AIGLX first came out. Over the same connection Gnome and KDE apps had more noticable lag.

    If like your saying that X apps are barely using X aymore, or at least using it less and less, then it may be a good time to redesign X protocol to make it easier to compress and avoid the ping-pong type client-server behavior that causes lots of performance issues over higher latency connections.

    It could be something that could be dramatically simplified over what is now.

    The security of X is one huge thing that is holding it back also. This is something that could be addressed. Especially when you move X completely off the hardware.

    Then people could keep the 'legacy xfree'-style server for backwards compatibility with older protocols.


    Just a suggestion.
    Last edited by drag; 12-15-2008, 04:02 PM.

    Leave a comment:


  • elanthis
    replied
    Actually, a few more questions for you Kristian. First, how do you think things like drag-n-drop and menus should be handled? X right now uses mouse/keyboard grabs, which I despise with all my being. That approach means that when an app has a grab and deadlocks (like Evolution seems to do one out of 20 times for me when trying to drag-n-drop messages between folders), the whole damn X session becomes completely and utterly unusable until I switch to a VT and SIGKILL the app. Will it possible in Wayland to implement those features, as well as things like windowed-games that want to track mouse position even when it's outside the window, without grabs?

    If not, would it at least be feasible to detect deadlocks (similar to the usual "this app is not responding" detection certain WMs have) and break the grab, and/or allow something like ctrl-alt-del or ctrl-alt-bksp to break it? Ideally there should be a key combination that always displays a non-overridable safe system dialog like Windows has, so you always have a way to take back control of the machine in the face of a badly behaving application, even if it's full-screen and has all input grabbed and is locked up (like a game). That's certainly possible in X with a little work. My second question is whether or not you already have plans for Wayland to support such a facility.

    The third question is: do you think Wayland should lock itself in memory (which may require root or partial-root privileges) so it never gets swapped out and thus cause the whole session to lock? Another problem related to dead-locked apps is apps that consume all the RAM and cause everything -- including the WM, X server (including input code), VT login processes, and so on to all be swapped to disk. Even switching to a virtual console to kill the app can end up being impossible, because it takes forever for X to switch VTs, forever to wait for the login process on the VT to be paged in, forever for the bash session to start, and then forever for kill/killall to start. Depending on the specific behavior of the app, the OOM killer might not ever kick in, so there's apparently no way to recover. I've had instances where I could manage to get to a logged-in console but killall couldn't manage to start even 2 hours after I typed in the command. Older versions of Firefox have done this to me on more than one occasion, as have a couple games.

    Thanks!

    Leave a comment:

Working...
X