Announcement

Collapse
No announcement yet.

Wayland, Weston 1.2 Release Candidate Are Out

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

  • #31
    Originally posted by dh04000 View Post
    Seriously, which major distro is going too? I'm bored of waiting.

    If wayland is so advanced and so far along and prefect in every way, such that the angels cry in its presense, why are you distros not installing it and running their GUI environments in XWayland? (People who don't want to run like this can just uninstall wayland, install xorg)

    So, very very very tired of waiting. Someone has to take the leap and do it. Let users break it and say what is and is not working.
    Because running your entire desktop in a compatabiltiy layer is pointless and potentially bug-ridden? Ubuntu running their entire unity desktop under xmir just seems silly to me. Not much point in being "first" if you are just running your entire desktop under xmir with x still doing most of the work...

    I don't get the "excitement" over running your entire desktop under a compatability layer.

    A lot of work needs to be done across the entire stack before wayland or mir can be "natively" adopted and used as default. EGL drivers need to mature, the toolkits, Gnome/KDE/Unity need to be fully ported etc... They can't just go "oh look mir/wayland is finished, lets all use it by default now!", the rest of the stack has to support it properly too. We should start seeing gnome-shell and KDE being able to run natively on wayland by next year. Gnome plans to have partial wayland support by the next version, and full wayland support (and used as default) by 3.12, and fedora is following gnome's timeline, they plan to have an optional wayland session in the next version of fedora, and wayland by default with gnome running *natively* on it by fedora 21. Other distros will probably begin to adopt wayland after fedora does, not all distros are bleeding edge and eager to adopt such new tech right away, there will be a "trickle" effect.

    We should see gnome and kde supporting wayland natively by 2014, and once they do bleeding edge distros will either offer it by default or as an optional session, and we should also see unity running natively on mir by 2014. Both of these projects are showing very similar estimated timeframes for adoption, and that makes sense because both of them need the rest of the stack to be ready before they can be adopted.
    Last edited by bwat47; 10 July 2013, 04:39 PM.

    Comment


    • #32
      Originally posted by GabrielYYZ
      I've been meaning to ask a couple questions for a really long time but never got around to it, if anyone can answer or, at least, give an educated guess it'll be much appreciated.

      Is it a bad idea to adapt weston to become the "standard" system compositor and use kwin/openbox/GNOME's/EFL's compositor as a session compositor? wouldn't that simplify much of the work the various DE's need to do? If not, why?
      ok, good question to extended mrugiero idea

      1.) remember wayland is a definition protocol not a server[biggest difference against X or Mir], meaning there is no wayland main process or anything
      2.) wayland don't composite or render or anything, it only give you a protocol to write your own "server"[<-- basically drm side buffering and IPC] or a compositor or a client.

      So what is weston for then? simple, is a living example of how to implement your own wayland compositor/server/client, nothing else

      Technically can weston and kwin work togheter? yes, if you comment some code in weston it can work as surface manager and Kwin/etc can composite[compositors are just clients in wayland, in Mir is an actual server so you can't]

      Why not use it? well weston is not written to be compatible or flexible or modular and is written in very low C and even if it is an excellent wayland compositor is too far behind in features compared to more complex compositors like Kwin/Gshell/etc.

      So it won't take more time to get DE native compositors? not really, in reality X11 can't support compositors without a lot of hacks and round abouts which is why it get bypassed almost entirely by any modern compositor like Kwin/Gshell/etc. and most of this work is already made in opengl/GL ES/EGL, so you just need to refactor your code to use Wayland[Wayland surfaces IPC + EGL] when available or use X11[X11 api + IPC + GLX or EGL] when is available.

      Any compositor beside Weston exist? yes Gshell 3.10 and Kwin 4.11[experimental]

      Why KDE4 or Gnome 3.8 don't use wayland then? well is relatively easy to composite in wayland so this can be done previously but your apps still are looking for an Xserver to send draw commands so you need the toolkits to learn how to write directly to a wayland surface[or use XWayland in a future] and that work is very advanced or almost completed in EFL/Qt5.1/GTK+-3.10 and now we are waiting for DE enviroments to port the remaining applications to use the new toolkits.

      So full native wayland DE are close? yes, Enlightment should be first in a month maybe, next is Gnome 3.10 close to Q3 release and next year KDE SC 5

      Comment


      • #33
        Originally posted by AJenbo View Post
        But isn't that simply the definition of major distros to you any way?
        if for you major distro equals ubuntu only you are maybe right.

        As example fedora a very popular distro if you watch.

        if not I would consider non-enterprise major-distros would be ubuntu, fedora, opensuse, debian (even thats a bit enterprisy ^^), maybe mint, and maybe arch.

        debian doesnt give a good example because it will get current software in 2 years. fedora and opensuse will not wait for nvidia to support wayland before they switch if they wait (maybe opensuse waits) its most probably not because of propriatary drivers but to experimental wayland support in gnome and kde...

        arch will not wait too, and I am pretty shure even debian will not make its desition to include wayland or not up because of propriatary driver support. So only ubuntu that will support wayland not anyway directly will wait for propriatary drivers.

        Or do you have another understanding what major distros are out there?

        Comment


        • #34
          Originally posted by GabrielYYZ
          PS: I knew most of it, so i didn't need the idiot's walkthrough but i don't mind you giving it for the sake of clarity. so, Thanks.
          was just in case someone with less knowledge than you were curious too but well most likely ubutrolls will just pass it unread and post "LOLz Westonz dontz minimize", so not sure how much of it is wasted time but well glad your doubt got cleared

          Comment


          • #35
            Originally posted by jrch2k8 View Post
            you need to get mesa 9.2, i use this pkgbuild http://pkgbuild.com/~lcarlier/mesa-git/x86_64/ and if you use radeon you can get ag5df kernel here
            Ah! thanks :-)

            Comment


            • #36
              Originally posted by mrugiero View Post
              I don't think two compositors can be a good thing. If you run a desktop, it shouldn't be any surface on the same level, so running that on top of a compositor that will only composite that surface is nonsense. As if it could be done, I have no idea. But I don't think there's any reason to.
              A system compositor is needed if you want seamless transitions between the login box and the desktop or when switching users and desktop environments, unless you start Kwin/Mutter very early and let them manage the login manager aswell (but then switching from KDE to GNOME wouldn't be seamless in this case). Since there's no "Wayland Server" running in the background to keep the display alive like on X, you need a system compositor to make the transition between the session ones.
              AFAIK KWin will work as a session compositor with Weston as the system one. As Weston will most of the time only be displaying a fullscreen buffer there shouldn't be any overhead.

              Comment


              • #37
                I asked on #wayland if there is an implementation of a system compositor right now. Pekka Paalanen answered that this would be something that replaces the kernels VT subsystem and offers logins etc. This is something that weston doesn't offer so I think you can't call it a system compositor.

                "Weston not designed to be modular" Then why is there a "modules" section in weston.ini? You can write your own desktop shell ontop of weston if you don't want to write your own session compositor. This is what this guy has been doing for example to get something like Gnome 2 on top of the weston compositor. https://plus.google.com/107691710289083956125/posts

                Comment


                • #38
                  Originally posted by blackout23 View Post
                  I asked on #wayland if there is an implementation of a system compositor right now. Pekka Paalanen answered that this would be something that replaces the kernels VT subsystem and offers logins etc. This is something that weston doesn't offer so I think you can't call it a system compositor.

                  "Weston not designed to be modular" Then why is there a "modules" section in weston.ini? You can write your own desktop shell ontop of weston if you don't want to write your own session compositor. This is what this guy has been doing for example to get something like Gnome 2 on top of the weston compositor. https://plus.google.com/107691710289083956125/posts
                  1.) yes so far system compositors arent here but it should in a while

                  2.) ok, yes you can write weston modules what i mean is in weston is not easy to implement modules complex enough to handle complex compositors because weston API is too low level, so you will need lot of glue to integrate properly into QT/KDE libs maybe not so much to GTK and this sense make much more sense to use QT5 compositor API for example or clutter.

                  another thing is weston internals miss many features needed for more complex compositors that will require prolly touch internal weston codepath and the module API, anyway i think martin can elaborate lot more here but that is the general idea.

                  an analogy could be "weston modules is like accessing a kernel module API directly on demand instead of using Qt5"

                  Comment


                  • #39
                    btw you don't need a compositor --read as render compositor-- at system level, a system compositor is more an internal subsystems police officer, to draw in the screen you only need a wayland client in FS and KMS[so a splash screen or a welcome image or session change, etc just need KMS to kick in].

                    a system compositor --read not render-- is more like make sure you have valid login before allow you to access the GPU or keep control of the input devices and assign it properly or keep/allow process to render and switch between them appropriately --read ctrl-alt-FX old way-- or coordinate render nodes or even filter operation to make sure the GPU is not compromised kinda thing but is not like a global Kwin or a system wide Compiz

                    Comment


                    • #40
                      Originally posted by GabrielYYZ
                      Damn, i had a multi-tasking brain fart... i meant "weston as system compositor and kwin/openbox/GNOME's/EFL's/etc as window managers in the form of plugins". The point of the question was the simplification (or so i think, i might be wrong) of the window managers by using weston as compositor, this is what i'm not sure of.

                      Thanks for answering, in any case.
                      It beats me. I don't know if Weston allows the use of plugins or if the panel can be disabled (no desktop would want Weston's panel, but own instead). But yeah, I guess if those two can be done, it could be used as a standard base.

                      Comment

                      Working...
                      X