Ubuntu 14.04 Codename Revealed, Mir Haters Attacked

[MWisBest]

By contrast, those same outraged individuals have NIH?d just about every important piece of the stack they can get their hands on? most notably SystemD, which is hugely invasive and hardly justified. What closely to see how competitors to Canonical torture the English language in their efforts to justify how those toolkits should support Windows but not Mir. But we?ll get it done, and it will be amazing.

Speaking of torturing the English language, jeeeeeeeeeeeeeeeeeez.

Anyways... long-live Wayland! Down with Mir! Rah Rah Rah! :P

[chrisb]

Answer: it has nothing to do with the kernel, actually. The user space driver targets the display system, not the kernel. In desktop Linux it's MIT, so they can do whatever they want. On Ubuntu based devices, it will be Mir, which is GPLv3 with exceptions when Canonical explicitly authorizes them. GPLv3 prevents you from locking your device, MIT does not.

If the user space driver requires a kernel shim that exposes custom syscalls then it has a lot to do with the kernel, and there are kernel developers who believe this to be a GPL violation:

The fact that user-space code is at issue is also significant. The COPYING file shipped with the kernel begins with this text:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
Normally, kernel developers see user space as a different world with its own rules; it is not at all common for kernel maintainers to insist on free licensing for user-space components. Dave's raising of licensing issues might also seem, on its face, to run counter to the above text: he is saying explicitly that closed user-space graphics drivers might be a work derived from the kernel and, thus, a violation of the GPL. These claims merit some attention.

The key text above is "normal system calls." A user-space graphics driver does not communicate with its kernel counterpart with normal system calls; it will use, instead, a set of complex operations which exist only to support that particular chipset. The kernel ABI for graphics drivers is not a narrow or general-purpose interface. The two sides are tightly coupled, a fact which has made the definition of the interface between them into a difficult task - and the maintenance of it almost as hard. While a program using POSIX system calls is clearly not derived from the kernel, the situation with a user-space graphics driver is not nearly so clear

[chrisb]

It is funny how you expect everyone else to spell out every single factor without any real understanding of what you are talking about. Have you wondered why Canonical choose to use GPLv3 and insists on a CLA for Mir? Do you have a good explanation of why Mir even exists? Matthew Garett isn't merely a software engineer but a Linux kernel developer and licensing expert. I will defer to his analysis over your non existest one. Sorry if that offends your sensibilities.

Your inability to explain your own position and your tendency to hurl insults at anyone who questions that position do not reflect well on you.

[makomk]

The idea with Wayland is making the already available compositors the "display servers", like KWin in KDE and Mutter in GNOME. Mir wouldn't be a problem at all if it used the Wayland protocol, but it doesn't. It uses its own.

Having the compositor be the display server was one of the main original selling points, but in practice they ran into fundamental problems - on multi-user systems everyone would have to use the same window manager and desktop, and also your choice of window manager would depend on your graphics drivers. So now they're splitting it into a Wayland "system compositor" running a "session compositor" which renders frames and passes them to the system compositor through a hardware-independent API, with the system compositor handling the driver-specific bits. In essence, they've returned to the old model of a separate compositor and display server in separate processes, just with a slightly different division of responsibilities. (Except that the major session compositors are expected to access the driver-specific APIs directly. So both the session compositor and system compositor will wind up containing a bunch of duplicated graphics driver-specific code.)

Even with all the variation in Linux distributions, developers have always been able to count on a common display server, X, and assume it to be used on any distro. With Wayland, the transition would have been painless, since Wayland would have provided XWayland, and developers could depend on the existence of either X or Wayland.

XWayland doesn't actually work properly. When people complain about it being so broken it makes Wayland unusable, they get accused of spreading FUD on the front page of Phoronix because it's officially not part of Wayland; same with any of the other essential parts of the Wayland stack like rendering libraries for clients. Wayland is small in the sense that almost everything is someone else's problem and officially not their fault.

Actually, I'm not convinced XWayland can ever work properly with all applications. Quoting from another front-page article here: "Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with. There is one known snag and thats with window transformations because app thinks its in the top right corner of the screen (yay global coordinates) because that client's X server is locked to the size of that client's window." What happens when an app has multiple top-level windows that are related in space? (I doubt Wine will ever work reliably under Wayland except in virtual-desktop mode either; Windows apps expect to know their window's global coordinates and that's intentionally impossible under Wayland.)

[blackiwid]

...

you point very corner cases, who many linux users dont care

1. with the driver stuff you mean they changed their stuff to support proprietary drivers right? thats than sad that we have a not so good architecture because of nvidia
2. wine who cares about wine... I dont want to run unfree software under linux, maybe in a sandbox vm like kvm but not really native. I have a seperate pc, it doesnt really make sense to install nsa-trojans and backdoors to your free software just use windows on such pcs in the first place and know its a rootkit.

So yes there are shurely solutions for that, but that you focus so hard and most evil stuff you could do with it tells much about your priorities.

But another big point, you do like wayland has big problems and MIR not, Mir is a piece of shit at least at the same amount then wayland is right now. Its also not usable for anybody it has no advantages for users. thats why they disabled it in the current ubuntu version. And even Xwayland is not usable. The only plattform they ship wayland instead of X is mobile... but there Xwayland does not work, so you cant run any linux apps, just this 10 garbage demo apps they developed for mir.

So yes Wayland isnt done yet yes but at least it seems gnome will be done in 5 months more or less. But general I dont see much benefit from neighter Mir or Wayland in short term, at the moment u cant bypass XWayland or XMir to do something usefull, and there you get worse Results (Benchmarks) so both is not ready for production yet.

So maybe you should look into Mir and show where all your problems you have are fixed there, show me the perfect running wine in mir (without XMIR) show me anything good there.

[chrisb]

Android drivers generally have open source kernel components even if the user-space bits are proprietary and binary-only.

I looked for some statistics to back this up and found this informal and out-of-date (2011) survey of Android tablets which indicates that, out of 138 Android devices surveyed, 118 had closed source kernel components, and 20 had open source kernel components. That's only 14.5% open source, so unless things have changed substantially since then, the majority of Android devices are using closed source kernel modules. (I would suspect that the number hasn't really changed, and that the number using closed source in phones would be slightly higher since they required a 3g chipset driver, but I haven't seen any surveys for Android phones)

I would be interested if anyone has seen more recent surveys?

[bridgman]

I looked for some statistics to back this up and found this informal and out-of-date (2011) survey of Android tablets which indicates that, out of 138 Android devices surveyed, 118 had closed source kernel components, and 20 had open source kernel components. That's only 14.5% open source, so unless things have changed substantially since then, the majority of Android devices are using closed source kernel modules. (I would suspect that the number hasn't really changed, and that the number using closed source in phones would be slightly higher since they required a 3g chipset driver, but I haven't seen any surveys for Android phones)

I would be interested if anyone has seen more recent surveys?

I haven't seen any more recent surveys but I picked a couple of chips at random from the "non-compliant" list (starting with Rockchip 2818) and found that source had eventually been published. That doesn't mean the source is complete or correct, of course, but my impression was that the balance had changed significantly over the last couple of years.

[RahulSundaram]

Your inability to explain your own position and your tendency to hurl insults at anyone who questions that position do not reflect well on you.

I asked you to read an analysis and educate yourself but instead you choose to call it flawed even though you missed the basic point that the link has nothing whatsoever to do with kernel drivers at all. When you are wrong, just admit it and move on. Don't pretend that you don't understand.

[dee.]

Having the compositor be the display server was one of the main original selling points, but in practice they ran into fundamental problems - on multi-user systems everyone would have to use the same window manager and desktop, and also your choice of window manager would depend on your graphics drivers. So now they're splitting it into a Wayland "system compositor" running a "session compositor" which renders frames and passes them to the system compositor through a hardware-independent API, with the system compositor handling the driver-specific bits. In essence, they've returned to the old model of a separate compositor and display server in separate processes, just with a slightly different division of responsibilities. (Except that the major session compositors are expected to access the driver-specific APIs directly. So both the session compositor and system compositor will wind up containing a bunch of duplicated graphics driver-specific code.)

There's nothing forcing one to use a system compositor in Wayland and in fact recent developments are moving away from a model of stacked system/session compositors. Even with a system where there is a system compositor and a session compositor, your assessment wouldn't be correct, as the system compositor only needs to do actual compositing when switching inputs between greeter/session compositor/etc. and the rest of the time it can be simply bypassed entirely.

The compositors will use EGL to access the graphics drivers and it's up to the actual graphics driver to provide the EGL interface, which should be identical between drivers.

XWayland doesn't actually work properly. When people complain about it being so broken it makes Wayland unusable, they get accused of spreading FUD on the front page of Phoronix because it's officially not part of Wayland; same with any of the other essential parts of the Wayland stack like rendering libraries for clients. Wayland is small in the sense that almost everything is someone else's problem and officially not their fault.

Xwayland isn't finished and not a lot of attention has been put into it yet. The developers' attention has been in other things, like preparing the entire graphics stack for a modern display system.

Actually, I'm not convinced XWayland can ever work properly with all applications. Quoting from another front-page article here: "Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with. There is one known snag and thats with window transformations because app thinks its in the top right corner of the screen (yay global coordinates) because that client's X server is locked to the size of that client's window." What happens when an app has multiple top-level windows that are related in space? (I doubt Wine will ever work reliably under Wayland except in virtual-desktop mode either; Windows apps expect to know their window's global coordinates and that's intentionally impossible under Wayland.)

None of these are problems that can't be solved.

[makomk]

There's nothing forcing one to use a system compositor in Wayland and in fact recent developments are moving away from a model of stacked system/session compositors. Even with a system where there is a system compositor and a session compositor, your assessment wouldn't be correct, as the system compositor only needs to do actual compositing when switching inputs between greeter/session compositor/etc. and the rest of the time it can be simply bypassed entirely.

Which again requires a bunch of functionality to be duplicated between the session and system compositors.

The compositors will use EGL to access the graphics drivers and it's up to the actual graphics driver to provide the EGL interface, which should be identical between drivers.

That's not actually sufficient for several reasons. Firstly, EGL doesn't support modesetting full stop. Secondly, it doesn't support the kind of buffer sharing Wayland needs - according to the architecture summary Wayland expects EGL drivers to "define a vendor-specific protocol extension that lets the client side EGL stack communicate buffer details with the compositor in order to share buffers" and only standardises the client-facing API for this, *not* the compositor-facing side. So every Wayland compositor needs driver-specific code in order to actually receive buffers to composite, including session compositors. Thirdly, not everything can support EGL - in fact, there was a front-page article a couple of days ago about a VNC backend that wasn't EGL-based and would use shared memory to receive updates from the compositor. (Also, some applications want full desktop OpenGL and not EGL, though I think that can be done in a driver-independent fashion unless they need GLX.)

None of these are problems that can't be solved.

The problems with XWayland/Wine and the lack of global screen coordinates are actually trivial to solve - it simply requires a way of accessing the global coordinates that all the Wayland compositors already track. Unfortunately, it's unlikely to ever happen. Not exposing those coordinates is a deliberate design decision the Wayland developers are very keen on sticking to. Same with some of the other problems - they're not bugs, it's intentionally designed that way.