Announcement

Collapse
No announcement yet.

Fedora 23 Likely To Pursue Wayland By Default

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

  • #11
    Originally posted by 89c51 View Post
    Wayland IS ready.

    The apps are not. Except if they use xwayland for the big and commercial ones.
    We knew it was somewhat "ready" even in 1.0 (at that state only means it is ready for developers), but ready for users also means apps are ready. Everthing most users (minus devs) care about is that apps can work, not kernel and not xserver/wayland.

    That said for the users, roughly speaking and with dev optimizm on the side i don't think it will be really ready in this decade and probably will need little bit more that that.
    Last edited by dungeon; 20 January 2015, 09:46 AM.

    Comment


    • #12
      Problem solved

      I think by far the easiest solution would be if Cannonical implemented the Wayland protocol in Mir.
      This way they can have the cake and eat it.

      For any uses on phones and tablets they can limit the application selections to MIR only, and on the desktop they can allow both.

      This way they can control the buffer allocation issue on phones, and on desktop, where this isn't an issue, people are free to use any app they want.

      I hope i'm not starting some war here

      Comment


      • #13
        Originally posted by adakite View Post
        How this will go while using Nvidia blob?! (ie. need cuda and high-end OpenGL support).
        sane people do not need proprietary shit like cuda
        and don't support with money anti-user companies like nvidia
        and high-end opengl will be available on open amd drivers by then

        Comment


        • #14
          distros like Fedora and Arch doesn't care about QA, so we need to wait to come into debian stable to be sure. Of course we are talking about Mutter Compositor. And I don't want to start a flame but Kwin will need systemd for use the wayland protocol, so Gentoo and Slackware are out of wayland for gnome and KDE..

          Comment


          • #15
            Originally posted by cocklover View Post
            And I don't want to start a flame but Kwin will need systemd for use the wayland protocol
            Not exactly. It needs something compatible with logind. A stub providing this could be implemented relatively easily, though all the systemd-related problems would remain (undocumented, moving target, etc.)

            Comment


            • #16
              Originally posted by pingufunkybeat View Post
              Not exactly. It needs something compatible with logind. A stub providing this could be implemented relatively easily, though all the systemd-related problems would remain (undocumented, moving target, etc.)
              No, socket activation will be used in place of KDE's existing home-made bash script for service management under wayland.

              Comment


              • #17
                Originally posted by pingufunkybeat View Post
                Not exactly. It needs something compatible with logind. A stub providing this could be implemented relatively easily, though all the systemd-related problems would remain (undocumented, moving target, etc.)
                Well I readed in the Martin Grassbling G+ account that OpenRC developers where asking or whining to KDE guys to not rely on systemd-logind. I'm not sure but I believe someone ask to KDE devs to implement logind feature in KDE or program openrc logind or something. And some Slackware guy was whining to.

                Comment


                • #18
                  Originally posted by Michael_S View Post
                  Competition never hurts, right? I still have the sense that Wayland development speed only shifted into high gear after Canonical announced Mir. So even if the only benefit to ever come from Mir is that it spurred improvements in Wayland, it's still a win.
                  Not really. Competition of implementations is useful (KDE, Gnome, Unity) because they can evolve, but competition among protocols doesn't really help that as they are stable by design. For protocols, it is better to have multiple inputs at design time rather than later on when it is too late. That, and the fact that Mir and Wayland are very similar in concepts but just incompatible in practice (shame).

                  Regarding development speed, this has been addressed countless times. The plan has always been "kernel and graphic stack work" (invisible to the general public) then "protocol and tools work" (visible to specialized public), and finally "application and windows managers work" (general public availability).
                  Mir has been started at the end of the first phase, because they couldn't have done it before. But the constraints were the same for weston and the wayland protocol work proper (phase 2). There is correlation of course, but no actual causation. We are now in phase 3, and it's going well (both for mir and wayland compositors).
                  It's not that bad in the end, but Mir sure led to duplicate work, without any actual benefit, even for canonical. Maybe it's too late, maybe it will go the way of bazaar and upstart. I don't think the cost of changing back would be that high.

                  Comment


                  • #19
                    Originally posted by adakite View Post
                    How this will go while using Nvidia blob?! (ie. need cuda and high-end OpenGL support).
                    Nobody at Fedora cares. The driver is not part of Fedora itself.
                    Ask NVidia.

                    Comment


                    • #20
                      Originally posted by skriticos View Post
                      Gnome 3 had a development head-start of almost four years on Unity 8. I'd be deeply surprised if they could catch up that fast.
                      Mir is not a from the ground up design. It reuses code from Android, Wayland, and so on. Qt, what Unity 8 uses, also has plugable back-ends.

                      Comment

                      Working...
                      X