Announcement

Collapse
No announcement yet.

Wayland Reference Code Being Re-Licensed

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

  • #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


            • #21
              Originally posted by elanthis View Post
              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.
              Oh I know exactly what LLVM is and what Clang is, and while Clang was nowhere near useable LLVM was piggybacking on the GCC frontend (gcc-llvm is being deprecated now though since they can piggy-back using the DragonEgg plugin instead).

              Originally posted by elanthis View Post
              Second, many companies are using and contributing to LLVM besides Apple. That includes several of those same companies that you list as GCC supporters.
              Using: yes, contributing: ...really?, can you point me to some examples? Maybe they are in the are of the JIT-framework because that's the area I'm not very into.

              Originally posted by elanthis View Post
              Not to mention larger Open Source projects using LLVM that are also backed by many of those companies you listed.
              Again USING is NOT CONTRIBUTING.

              Originally posted by elanthis View Post
              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).
              Please show me some examples of 'directly' supporting (as in code or money) LLVM by these said companies. Wtf is indirectly supporting? Giving thumbs up?

              Originally posted by elanthis View Post
              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.
              Lol are you saying that Red Hat are not stout proponents of GPL? And no I totally disagree. From a company standpoint when it comes to CONTRIBUTING, GPL makes alot more sense. When it comes to USING, then obviously BSD-style licencing is more attractive.

              Originally posted by elanthis View Post
              Third, Clang is not being backed by Apple solely (or even primarily) because of the license.
              Yes they are, if they could have used GCC as a frontend for their proprietary development tools they would never have bothered with funding Clang development. Jobs already tried to evade GPL and keep their ObjC frontend proprietary while using the GCC backend back in the NeXT days, it didn't fly.
              Recently they took DTrace and built their proprietary 'instruments' from it as part of their proprietary development suite XCode, there's an obvious pattern here.

              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, making it impossible to use GCC for all of the very cool things that Clang is explicitly designed to support.
              Ahh, so you are just some zelot with hatred for RMS, explains alot. In fact, explains ALOT. I don't agree with RMS's opinion that proprietary code is EVIL, but douchebag? Lol, coming from a whiny prick like you that's hilarious.

              Originally posted by elanthis View Post
              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).
              I'm pretty certain you can use the plugin interface for that. And yes that ideology is what the GPL licence is BASED upon, you know, that licence which is by FAR the most used open source licence. Obviously you don't have to go for the whole FSF ideology to use the licence, but the 'grant to other recipients the same rights granted to you' is what makes the licence tick.

              Comment

              Working...
              X