Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: Dual X Servers Running Side-By-Side With Wayland

  1. #11
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,403

    Default

    I'm just guessing, but I don't think krh wrote an X server replacement here; this would probably be X in its current form with drivers that use Wayland for drawing rather than hitting hardware directly.

  2. #12
    Join Date
    Nov 2008
    Posts
    2

    Default

    I'm no expert, but I would guess he can make a lot of progress since there is nothing stopping him from using existing Xserver and X.org code. It's not like he's starting completely from scratch...we all have the privilege to watch open source's benefits in action. I hope he continues making progress.

  3. #13
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by bridgman View Post
    I'm just guessing, but I don't think krh wrote an X server replacement here; this would probably be X in its current form with drivers that use Wayland for drawing rather than hitting hardware directly.
    oh it uses the hw alright, it just redirectks kms front buffers to wayland.

    all this stuff needs kms.

    Dave

  4. #14
    Join Date
    Dec 2008
    Posts
    2

    Default

    I have a FAQ page over in the Google group for the project that answers many of the questions here:

    http://groups.google.com/group/wayla...keds-questions

    cheers,
    Kristian

  5. #15
    Join Date
    Dec 2007
    Posts
    677

    Default

    Thanks for the faq

  6. #16
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    365

    Default

    Hey, just wondering wether running two x servers under wayland could finally solve the "no minimizing in Linux" problem: Imagine the primary X server running under Wayland. The user starts some game, which gets hosted on a second x server, but wayland just draws the content of the second x server's front buffer. Now, if the user presses some key-kombo, Wayland renders only the first front buffer. Of course, there still needed to be done some hacking on mode setting (i.e. when the game starts), but technically this sounds feasible, doesn't it?

  7. #17
    Join Date
    Sep 2006
    Posts
    714

    Default

    Here let me explain something to you about XServers.

    There are already lots and lots of X Servers.

    A few off the top of my head are:

    Xnest -- runs a embedded X server on your desktop.
    Xephyr -- Replacement for Xnest that includes acceleration features.
    Kdrive -- small X server
    Darwin -- X for OS X
    DMX -- distributed multihead X (with Chromium you can get distributed OpenGL acceleration, btw)
    Xfree -- the default X server from X.org

    So X.org provides the 'X Window System'. 'X Windows' as you probably know is a network protocol. Like HTTP.

    So your X Server is equivalent to your Web Browser.
    Then X Clients are equivalent to Web Servers.
    X Clients talk to X servers using X Windows. Web Servers talk to Web Browsers using HTTP.

    Now the only confusing part is that the 'X Server' part of X Windows is almost always on your local computer. So it's a bit opposite from the terms we normally use. This gives you a idea about how old X Windows is.

    Anyways...

    So the 'X Window System' is divided up into two parts:
    DDX -- Device Dependent X
    and then
    DIX -- Device Independent X.

    The X Server is the DDX stuff. X.org provides many different sorts of DDX's.

    DIX is all the libraries and stuff that X.org provides that is used by various applications and toolkits to build X clients.


    Soo....

    If you think that Wayland is some sort of upstart or challenger to X.org then think again. That's just not how this works. Wayland is still going to have huge dependencies on X.org-provided stuff in order to work.

    Anyways...

    from his own blog:
    http://hoegsberg.blogspot.com/2008/1...r-than-no.html
    The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.
    Sooo... It's not really a X Server at all and is not intended to be a replacement.

    Instead if your going to be using it to run X Windows application you will have a X Windows server running, but with all the pixmaps rendered off-screen.. Then Wayland takes those pixmaps and sucks it down using it's own composted manager.

    So it's a new sort of display manager that can use pixmaps displayed from a existing X Server.

    Or something like that. Don't really understand all of it.

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

    Maybe the goal is to get a X Server running as a sort of daemon or something were you can then separate the X stuff from the Display stuff. Then you can possibly have detachable sessions (like using bash + screen) or have you application survive a driver crash or allow people to turn off the display directly and redirect it to other hardware or systems.

    Or something like that. Like I said I don't really understand the point exactly.

  8. #18
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Drag: Wayland does replace the X server at one level of the stack. It can in time completely replace the X server: you don't have to run an X server at all with Wayland, unless you want to run existing X clients.

    Assuming Wayland actually gets to a usable and complete point, and the design is proven solid, then developers can start porting apps (or toolkits, really) to Wayland's native protocol. Assuming all of your apps are ported, there'd be no need for you to have an X server running at all. You could fire up an X server on-demand for apps that need it, such as old closed binaries or old unported apps. That scenario is probably a good number of years away, though.

    If you read the FAQ Kristian posted, that's all spelled out for you. It's pretty clear and informative.

    The only thing I don't see answered (plz to answer Kristian kthxbai) is whether or not Wayland's protocol intends to support remote connections; if not, X would remain useful indefinitely for remote client support, but not for local clients.

    The point of Wayland is essentially that 90% of what X does isn't necessary any more: all of the hardware setup is done in the kernel, all of the rendering is done in the clients, and all of the input events are handled by unified driver interfaces. Nested windows are considered harmful these days, the mandatory core X drawing protocol is essentially unused, and even RENDER is being replaced by clients doing rendering straight to pixmap buffers using GL. The only thing X is really needed for (aside from network support) is the functionality that Wayland provides, but Wayland does it without all the legacy protocol requirements. In the short term, Wayland is only useful as an X session multiplexer. Long term, it has the potential to make X unnecessary for most setups.

    It's a really neat total redesign of the graphics stack in face of KMS/GEM/DRI2/EGL, and because X can so easily be run as a nested client, it can be done in a very transition-friendly manner so there's no "port or die" mandate like so many other software replacements force on developers. Pretty cool.

  9. #19
    Join Date
    Dec 2008
    Posts
    2

    Default

    Quote Originally Posted by elanthis View Post
    Drag: Wayland does replace the X server at one level of the stack. It can in time completely replace the X server: you don't have to run an X server at all with Wayland, unless you want to run existing X clients.

    Assuming Wayland actually gets to a usable and complete point, and the design is proven solid, then developers can start porting apps (or toolkits, really) to Wayland's native protocol. Assuming all of your apps are ported, there'd be no need for you to have an X server running at all. You could fire up an X server on-demand for apps that need it, such as old closed binaries or old unported apps. That scenario is probably a good number of years away, though.

    If you read the FAQ Kristian posted, that's all spelled out for you. It's pretty clear and informative.

    The only thing I don't see answered (plz to answer Kristian kthxbai) is whether or not Wayland's protocol intends to support remote connections; if not, X would remain useful indefinitely for remote client support, but not for local clients.

    The point of Wayland is essentially that 90% of what X does isn't necessary any more: all of the hardware setup is done in the kernel, all of the rendering is done in the clients, and all of the input events are handled by unified driver interfaces. Nested windows are considered harmful these days, the mandatory core X drawing protocol is essentially unused, and even RENDER is being replaced by clients doing rendering straight to pixmap buffers using GL. The only thing X is really needed for (aside from network support) is the functionality that Wayland provides, but Wayland does it without all the legacy protocol requirements. In the short term, Wayland is only useful as an X session multiplexer. Long term, it has the potential to make X unnecessary for most setups.

    It's a really neat total redesign of the graphics stack in face of KMS/GEM/DRI2/EGL, and because X can so easily be run as a nested client, it can be done in a very transition-friendly manner so there's no "port or die" mandate like so many other software replacements force on developers. Pretty cool.
    That's a pretty good writeup of the major points in Wayland. As for the question about remote client support: no, I consider that outside the scope of Wayland. If you want remote rendering, Wayland is a good environment for running your remote display server such as X.org or an RDP server or similar, either full-screen or in a root-less fashion. Or somebody can invent their own remote display protocol on top of Wayland.

    I've been thinking that maybe it's possible to implement a "remote compositor" that forwards the Wayland requets over the network to a remote display, but I haven't spent much time on that idea

  10. #20
    Join Date
    Apr 2008
    Location
    /dev/random
    Posts
    218

    Default

    Would it be something like the compiz/dmx NOMAD patches?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •