Announcement

Collapse
No announcement yet.

Wayland Reference Code Being Re-Licensed

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

  • #11
    Originally posted by FireBurn View Post
    I wished it had gone to LGPL I feel this might have encouraged more companies to give back to the project
    The GPL tends to prevent companies from putting themselves in the situation where they have anything to give back. I think Michael has a write-up about how this was happening with GCC.

    Comment


    • #12
      Originally posted by pingufunkybeat View Post
      Wayland is not a successor to Xorg.
      What we are hoping is that with some luck, it might become a viable alternative to Xorg on the desktop.
      If all goes well, then eventually, Wayland will make X.org archaic.

      Comment


      • #13
        Originally posted by Shining Arcanine View Post
        The GPL tends to prevent companies from putting themselves in the situation where they have anything to give back. I think Michael has a write-up about how this was happening with GCC.
        I'm not sure many people have a problem with the LGPL. GCC is GPL, for example.

        Comment


        • #14
          Originally posted by DanL View Post
          If all goes well, then eventually, Wayland will make X.org archaic.
          X.org IS archaic. But, Wayland will just be a "awe isn't that cute, they wrote a new display" project without support from nVidia and AMD's drivers.

          Comment


          • #15
            Originally posted by yogi_berra View Post
            X.org IS archaic. But, Wayland will just be a "awe isn't that cute, they wrote a new display" project without support from nVidia and AMD's drivers.
            Wayland support should be much easier than X support for them, so I wouldn't expect that to be a problem.

            Comment


            • #16
              Well first the open drivers should support it better.
              On mesa 7.12 on HD 6550 (= HD 5650) it looks like this (background picture screwed, mouse leaves a trail, ):

              Code:
              $ EGL_LOG_LEVEL=debug wayland-compositor -b 01657_waterfallinthewoods_1680x1050.jpg
              libEGL debug: Native platform type: x11 (autodetected)
              libEGL debug: EGL search path is /usr/lib/egl
              libEGL debug: added /usr/lib/egl/egl_gallium.so to module array
              libEGL debug: added egl_dri2 to module array
              libEGL debug: added egl_glx to module array
              libEGL debug: dlopen(/usr/lib/egl/egl_gallium.so)
              libEGL info: use X11 for display 0x2496370
              libEGL info: created a pipe screen for r600
              libEGL debug: the best driver is Gallium
              XDG_RUNTIME_DIR not set, falling back to .
              using socket ./wayland-0

              In the framebuffer with no X running it looks worse.
              Code:
              libEGL debug: Native platform type: drm (autodetected)
              libEGL debug: EGL search path is /usr/lib/egl
              libEGL debug: added /usr/lib/egl/egl_gallium.so to module array
              libEGL debug: added egl_dri2 to module array
              libEGL debug: added egl_glx to module array
              libEGL debug: dlopen(/usr/lib/egl/egl_gallium.so)
              libEGL info: use DRM for display 0x7c6670
              libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no usable display)
              
              libEGL debug: the best driver is DRI2
              compositor: using /dev/tty1
              XDG_RUNTIME_DIR not set, falling back to .
              using socket ./wayland-0
              No usable display? Oh really?
              But wayland is running, graphics are broken and somehow the framebuffer contents from X often flicker through (this time I started from a tty it with X running)...

              Moving the cursor produces just flickering
              Code:
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64
              info: cursor stride is != 64

              Starting a client doesn't seem to do anything.
              Code:
              $ wayland-terminal
              XDG_RUNTIME_DIR not set, falling back to .
              Internal error:   Could not resolve keysym SunProps
              Internal error:   Could not resolve keysym SunFront
              Internal error:   Could not resolve keysym SunOpen
              Unknown parameter: ?1034
              Also the file view.c in the wayland git repository includes wayland-glib.h. But wayland-glib.h is not in the git repository.

              So I too like wayland but it is apparently still not in a usable state.

              Comment


              • #17
                Originally posted by ChrisXY View Post
                So I too like wayland but it is apparently still not in a usable state.
                On the bright side, you likely won't be using that compositor when Wayland goes mainstream anyway. It'll be the compositor built into (or, alternatively, using) the Qt or Gtk framework, depending on which environment you're using.
                😸

                Comment


                • #18
                  Originally posted by Shining Arcanine View Post
                  The GPL tends to prevent companies from putting themselves in the situation where they have anything to give back. I think Michael has a write-up about how this was happening with GCC.
                  Really? I find that in reality it's the exact opposite, compare the company support for GCC (GPLv3) where we have IBM, Red Hat, CodeSourcery, Suse, Intel, AMD, Google etc are all contributing, many of them with full-time employees working on GCC. Meanwhile LLVM (BSD-style licence) has corporate backing from Apple, and the reason Apple started supporting llvm/clang is that they want to incorporate it into their proprietary compiler solutions (XCode), which they couldn't do with GCC (read up on Jobs ObjC gcc frontend debacle). Despite LLVM having been around for 11+ years it hasn't attracted any real corporate backing outside of Apple, so on the contrary I'd say companies prefer cooperating under GPL (where everyone must share their enhacements) rather than BSD (where companies can take the enhancements provided by others and keep their own to themselves).

                  That said, I think LLVM is great, and apart from the much warranted competition it offers, it also functions as the de facto standard JIT-framework for foss projects so in that respect it's already a core part of the open source ecosystem.

                  BTW, where was this article you were talking about?

                  Comment


                  • #19
                    Originally posted by XorEaxEax View Post
                    Really? I find that in reality it's the exact opposite, compare the company support for GCC (GPLv3) where we have IBM, Red Hat, CodeSourcery, Suse, Intel, AMD, Google etc are all contributing, many of them with full-time employees working on GCC. Meanwhile LLVM (BSD-style licence) has corporate backing from Apple, and the reason Apple started supporting llvm/clang is that they want to incorporate it into their proprietary compiler solutions (XCode), which they couldn't do with GCC (read up on Jobs ObjC gcc frontend debacle).
                    First, you're confusing LLVM with Clang. Clang uses LLVM, but LLVM is not Clang, and they do not do the same things at all. GCC is not comparable to LLVM on its own, as GCC is a complete compiler and LLVM is not.

                    Second, many companies are using and contributing to LLVM besides Apple. That includes several of those same companies that you list as GCC supporters. Not to mention larger Open Source projects using LLVM that are also backed by many of those companies you listed. In fact, the only company you listed that isn't either directly or indirectly supporting LLVM to my knowledge is CodeSourcery (and maybe they are and I simply don't know about it). You're not going to see direct support on the compiler from companies like Red hat or Suse simply because they were already suppoyrting GCC long before anyone even thought of Clang and have no reason to switch at this time; it's not because GCC's license somehow makes it more palatable to them.

                    Third, Clang is not being backed by Apple solely (or even primarily) because of the license. Clang is being backed because RMS is a douchebag that intentionally sabotaged the usefulness of GCC for years out of fear of evil proprietary code monkeys, making it impossible to use GCC for all of the very cool things that Clang is explicitly designed to support. If Clang where LGPL or even GPL Apple would be just as happy to use it (and in fact Apple has had no problem with the GPLv2). The Clang Xcode integration (which still uses GCC for its compiler by default, iirc) is happening because Clang actually makes that kind of integration possible in the first place while GCC is utterly incapable of being used for IDE code-completion and the like (independent of the actual license and purely due to architecture and the politics that enforce that shitty architecture in order to more strongly enforce an ideology).

                    Comment


                    • #20
                      Originally posted by elanthis View Post
                      Clang is being backed because RMS is a douchebag that intentionally sabotaged the usefulness of GCC for years out of fear of evil proprietary code monkeys
                      Ehh...you lost me. How is sabotaging a compiler with a less permissive license, then switching to (and improving) a compiler with a more permissive license, going to hurt "evil proprietary code monkeys"?

                      Comment

                      Working...
                      X