Originally posted by FireBurn
View Post
Announcement
Collapse
No announcement yet.
Wayland Reference Code Being Re-Licensed
Collapse
X
-
-
Originally posted by Shining Arcanine View PostThe 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
-
Originally posted by yogi_berra View PostX.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
-
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
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
So I too like wayland but it is apparently still not in a usable state.
Comment
-
Originally posted by ChrisXY View PostSo I too like wayland but it is apparently still not in a usable state.
😸
Comment
-
Originally posted by Shining Arcanine View PostThe 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.
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
-
Originally posted by XorEaxEax View PostReally? 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).
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
-
Originally posted by elanthis View PostClang 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
Comment
Comment