Mir Development Stats Dominated By Canonical

[XorEaxEax]

Test code (unit tests) are not supposed to be pruned, nor have anything to do with having found or not the best approach.

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).

[shaunehunter]

Illustrates my point.

wayland on the Nexus 4 with multitouch from july 2012

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.

[bkor]

Canonical wants to start putting out devices this fall. Wayland's ETA is sometime'ish. "Doing it right" has no value if it never gets done. Canonical seems to want Mir to be compatible with Android drivers and that may be the right call. I imagine the wayland team was about as receptive to working with Canonical as the GNOME project was.

Fact:
1. Canonical took another project developed for Wayland to be able to run Mir with Android drivers.
2. Canonical never contacted Wayland developers about their needs.

It would be good to investigate a little bit. Both things are repeated often, doesn't make it true.

[bkor]

Canonical deserves respect here.

They contributed to Wayland, planned to do some work. Suddenly stopped, only to tell 6-9 months later that they've been working on Mir. They could've talked to Wayland developers. They could've participated. They chose to do things in secret and go on their own. Things would be quicker if you work together. I don't see why respect is deserved.

That said, wish them all the best and if they succeed, cool. But that's it.

[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]

[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]

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]

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.

[mrugiero]

iirc CLOC neatly lists code, comments and blank lines separately

It does, according to its description.

[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.