Mir Development Stats Dominated By Canonical

[erendorn]

Also, if a claim I read about in this or another thread is true (I don't know, since the poster never pointed me to any official source), most of the fast development of Mir was due to a HUGE reutilization of Wayland's code.

Reuse of libhybris (compatibility with android drivers). for xMir xWayland, couldn't find reliable source, and too complicated to compare code myself.

[GreatEmerald]

Wayland is a PROTOCOL Mir is actually a SERVER like X11 but without the fat, if you can't tell the difference means you are not an engineer or you wasted a lot of time and money in that university.

I have no idea why you're quoting me, of all things. My point was that Mir did not accelerate the development process of Wayland.

I know full and well what unit testing is, but I quickly misread it as test code (as in trying different approaches/solutions, most of which will be discarded).

The reason I did this is because Wayland and Weston obviously also has a lot of unit test code, so the reason Mir has more LOC than Wayland is very unlikely to stem from that. Again it could just be a ton of comments making Mir larger as Michael stated in the post that he included them (why? iirc CLOC neatly lists code, comments and blank lines separately).

No, Ohloh count comments separately from lines of code and whitespace. Mir has 160k lines of actual code, Wayland has 12k, Weston has 53k.

[jrch2k8]

I did read the docs. The fact Wayland doesn't do any drawing doesn't mean it doesn't act as a server, and that's one of the things that wasn't clear on your previous post (and lead me to think you were under severe misunderstanding).
From the main page:

Obviously, I recalled it incorrectly, where it says it can be, I recalled it was, when it's just a possible way to implement it.
You was (wrote are, but meant was) still wrong with X11 (that's a protocol, and the server normally used is X.org), and from what I read on Mir's spec, about Mir, since it doesn't seem to handle the drawing but the compositing, just as Wayland do.
I'm aware of all the advantages of Wayland, I read the docs (not to the end, yet) because I want to port my pet pr
oject to Wayland.
Anyway, I obviously misunderstood you, I actually thought your post was trying to say Mir was a far better option. I specially misunderstood what you meant with GPU language specification. It sounded like they were redesigning OpenGL or something like that, not just making use of DRI as I'm aware they do.
On another subject, civility is not at all overrated, man, and your HUGE FONTS and BOLDS are pretty impolite.

well to extend a bit in this topic wayland is not a server at all and it can't be not just because it doesn't draw, as a reference X.Org doesn't necessarily draw either[unless you use motif directly <-- insanity].

so what make an protocol like Mir and X11 server type? well, with either of this two Mir and/or X.org are global processes that handle the interaction between GPU[positioning/input/referencing/rendering/surfaces/subsurfaces/etc] and the clients, this means and X.org or Mir application can't access the framebuffer of the GPU directly, they have to request the operation to this global middleman in between and this apply to the compositors too, they have to request and process the framebuffer to this middleman talking an API this middleman can understand, so the middleman later can render the completed frame.

what make Mir different from X.org? well basically Mir trimmed all the fat of the X11 protocol and try to be a less intrusive middleman allowing you more freedom in the render process, in theory Mir can be atomic and properly threaded too[TODO for now] and uses EGL instead the GLX mammut but still is a global process middleman that you have to request operations even so you have to do lot less roundtrips than you would with X11.[you can confirm this checking their own examples and looking at your process table]

so, why wayland is not a server then? keeping your words wayland is more close to an OpenGL for Framebuffer management than to X.org or Mir. let see it this way, you can do everything wayland does using pure EGL/OpenGL or even GPU ASM, is not a big deal at all and the performance advantage is nasty but if everyone do this their own way basically would be a hell of a mess that will force you to use 1 computer per application, so all christian did was think of an standard library that can send this object directly from the application to the GPU in an standarized fashion so we can all use it. So yes that it is wayland is nothing more that a library of premade objects that you can send to a GPU to do window surface operations directly.

so why wayland need a compositor? it doesn't need one at all and is not part of the spec either

so what is a wayland compositor? put simply a client or application that other applications that use the wayland protocol register objects with, so it can keep a global idea of how the framebuffer is looking in a given period of time and do operations with that information[change a surface position for example or add eye candy], in resume a compositor is a good added value but is not necessary

in which god's case i would not use a compositor? full screen games or any type of full screen application, yeap just create a surface that match the entire display size then render something into it and swap it, 100% GPU dedicated to your APP like magic

so how wayland/client relate? you app using the wayland protocol create an usable surface, then your app draw something in that surface using any API you like[OpenGL, OpenVG, GPU ASM, Pixman, etc] then your app inform the compositor it have an valid surface at X,Y,Z[in case is not fullscreen] and the compositor simply re render a surface as big as the screen[that include your app and other apps surfaces] and post-process it to give you a final surface composited from all other subsurface

so in resume when your app is linked to libwayland your app not wayland send packages of operation directly to the GPU, use wayland isn't any different than use a let say a jabber protocol library or libtorrent protocol library, in perfect english everything is on you because wayland do absolutely nothing at all beyond provide you with premade operations to start a valid surface in the GPU[ofc if you use tollkits like Qt or Gtk they do the heavy lifting]

i hope is more clear[and obviously is very simplified], about been polite is hard sometime when you explain the same thing in 200 different post and ppl still come and say "Lulz wayland don't minimize" or any other barbaric assumption without properly investigate before hand

[bananaoomarang]

Oh my... You mean... Jesus.... The majority of development on Mir is Canonical funded!!!! OMG! :P

In all seriousness, it will be interesting to see how much better than Wayland (technically) this ends up being, or if it'll just be another Upstart.

[MartinN]

http://samohtv.wordpress.com/2013/03...as-a-new-home/

Now you can eat your words and my ass.

P.S. Don't be rude.

That would carry a lot more merit if it came from NVidia's mouth. I'm not dissing their working relationship - there might be one, but NVidia has yet to issue any kind of official statement/PR stating their support for Mir or Wayland or whatever underlying architectural changes they need to do to their driver relating to GL/EGL that will support the work of both.

I remain hopeful that NVidia will do that soon, or it will be Intel (HD) eating everyone's lunch real soon now.

[mrugiero]

iirc CLOC neatly lists code, comments and blank lines separately

It does, according to its description.

[mrugiero]

Wayland is not acting as a server nor is implemented as one[read the code at least dude].

With Mir and X11 you ask the server to render this content in surface A, then set focus for input at this coordinates and return an event with a server side API, so the server check and process the requirement, in plain english is a police middleman.

Wayland on the other hand is a pure protocol and it does define an API ish way to talk directly to the GPU, wayland doesn't coordinates/handle/interfere with the process in any way, it just generate pointers and minimal references so the compositor can handle surface positioning and input. in fact i can have X application that use my system global libwayland 1.1 and render using Pixman and Y application staticaly compiled with wayland Git that uses EGL and Opengl 3.1 profile to render and Weston[mutter/kwin/etc] won't even know because im talking directly to the GPU and wayland API just return objects with location information and surface information[screen/gpuX/position in internal GPU framebuffer/color depth/colors type/etc] for every specific client, so the compositor later with this minimal information can organize the screen later to present it in any way you like.

see this for an example http://www.youtube.com/watch?v=_FjuPn7MXMs

so to be more precise Mir and X11 are server type Protocols and Wayland is an direct GPU access Protocol, don't believe well start any wayland client app or demo and try to locate the wayland server process i dare you and for god sakes before reply a thread read the freaking code or read the documentation[wayland site even have cool diagrams and big fonts]

I did read the docs. The fact Wayland doesn't do any drawing doesn't mean it doesn't act as a server, and that's one of the things that wasn't clear on your previous post (and lead me to think you were under severe misunderstanding).
From the main page:

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.

Obviously, I recalled it incorrectly, where it says it can be, I recalled it was, when it's just a possible way to implement it.
You was (wrote are, but meant was) still wrong with X11 (that's a protocol, and the server normally used is X.org), and from what I read on Mir's spec, about Mir, since it doesn't seem to handle the drawing but the compositing, just as Wayland do.
I'm aware of all the advantages of Wayland, I read the docs (not to the end, yet) because I want to port my pet pr
oject to Wayland.
Anyway, I obviously misunderstood you, I actually thought your post was trying to say Mir was a far better option. I specially misunderstood what you meant with GPU language specification. It sounded like they were redesigning OpenGL or something like that, not just making use of DRI as I'm aware they do.
On another subject, civility is not at all overrated, man, and your HUGE FONTS and BOLDS are pretty impolite.

[jrch2k8]

Where can I get the ROM, what distro packages it, does it actually run programs, can I still make a call?

Ubuntu's is right here ready to go.
https://wiki.ubuntu.com/Touch/Instal...InstallProcess

I am rooting for Wayland but this is the current state of things. Canonical deserves respect here.

well i have a nexus 7 32Gb and tried the ubuntu stuff and is basically useless[only demo data and images of what should be in the future] but i have to agree is a lesser geek demo than wayland's.

for the sake of responding yes any Qt5 + qtwayland QPA or GTK+ 3.8 real application will work in Wayland in both X86 and ARM and with a bit of effort Xwayland can run X11 apps in arm using full accelertation with android drivers and all[libhybris].

no there is no cool premade image with cool images and stuff yet for this, if you want you need real apps meeting the requirements above and a source distro like gentoo to get thing compiled the right way

fix: seems for raspberry there are some premade distros that use Qt5 demos and wayland, check the rasp forum.

as a note: wayland is basically ready and mostly fixing corner cases in the protocol like subsurfaces and age extension, we aren't waiting for wayland anymore but for the clients EFL/Qt5/Gtk-3.10/etc and their respective desktops KDE SC 5/Enlightment/Gnome 3.10 to be ported to wayland, so is very likely that when Mir sees the first beta of unity 8 Gnome will be able to work 100% on wayland with Mutter as compositor and all and for the final Mir release time at least KDE SC 5 will have a beta/rc release.

ofc wayland will get new features over time but the base protocol is frezee since some time now, which is why you see minimal activity in the repos this days[most work is going to mesa and kernel DRM to handle the bufferage extension]

[mrugiero]

I know full and well what unit testing is, but I quickly misread it as test code (as in trying different approaches/solutions, most of which will be discarded).

The reason I did this is because Wayland and Weston obviously also has a lot of unit test code, so the reason Mir has more LOC than Wayland is very unlikely to stem from that. Again it could just be a ton of comments making Mir larger as Michael stated in the post that he included them (why? iirc CLOC neatly lists code, comments and blank lines separately).

You are right, it says so in the description.

[jrch2k8]

yes, Wayland is a protocol, which gets implemented as a display server. X11 is a protocol too, which is implemented as a server, too.
And, no, the rendering and the names are unrelated. And that about the GPU language specification, I'm laughing my ass off.

Wayland is not acting as a server nor is implemented as one[read the code at least dude].

With Mir and X11 you ask the server to render this content in surface A, then set focus for input at this coordinates and return an event with a server side API, so the server check and process the requirement, in plain english is a police middleman.

Wayland on the other hand is a pure protocol and it does define an API ish way to talk directly to the GPU, wayland doesn't coordinates/handle/interfere with the process in any way, it just generate pointers and minimal references so the compositor can handle surface positioning and input. in fact i can have X application that use my system global libwayland 1.1 and render using Pixman and Y application staticaly compiled with wayland Git that uses EGL and Opengl 3.1 profile to render and Weston[mutter/kwin/etc] won't even know because im talking directly to the GPU and wayland API just return objects with location information and surface information[screen/gpuX/position in internal GPU framebuffer/color depth/colors type/etc] for every specific client, so the compositor later with this minimal information can organize the screen later to present it in any way you like.

see this for an example http://www.youtube.com/watch?v=_FjuPn7MXMs

so to be more precise Mir and X11 are server type Protocols and Wayland is an direct GPU access Protocol, don't believe well start any wayland client app or demo and try to locate the wayland server process i dare you and for god sakes before reply a thread read the freaking code or read the documentation[wayland site even have cool diagrams and big fonts]