KDE Vivaldi Tablet Finally Shipping For QA Testing

[dee.]

Canonical said they had to bring abilities into their court as the solutions out there didn't suit their direction [paraphrasing]. The reason why they dropped Wayland and coded for their own needs.

All of the technical reasons they have stated for why they couldn't use Wayland have been shown to be 100% false. Do you know of any new technical reasons why they would need to use Mir that I haven't heard of? Shuttleworth is just making vague statements about there being some undefined things wrong with Wayland, when he's not simply plain lying and/or talking out his ass. The truth is, every supposed "advantage" of Mir (as presented by various Canonical employees) have been shown to be non-existent: Android driver support? Came from Wayland originally. Server-side buffer allocation? Can be done in Wayland. Canonical wants control of the display server? Not a problem, Wayland is a protocol - just implement your own compositor and have all the control over the codebase you ever want - like others are doing right now. Can't be used in a phone? False, Jolla is using it and their first phone is getting on the market before any Mir phone.

What it comes down to is political reasons. Maybe Canonical wants to separate Ubuntu from other Linux operating systems? Well, as a company that is 99% dependent on the work of the community, ie. the other Linux systems, it's still a stupid move and very, very likely to blow up on their face. Or maybe they "want the freedom to break APIs if needed and not follow a set protocol" (as I'm sure I've heard either Bacon or Shuttleworth saying) - which... pretty much amounts to the same thing, really: with that reasoning, it becomes very, very clear that it's a solution that only suits the purpose of one single user (Canonical), will not support interoperability between different implementations (anyone other than Canonical), and that it's a conscious effort to actually *break* compatibility between Ubuntu and other Linux systems.

But this wasn't about Canonical's reasons. You were earlier in the thread shouting about how KDE is stupid because they don't use Mir, and that you think they should use Mir. Since you said it, I've for the last 3-4 posts been trying to get you to answer me why exactly do you think anyone other than Canonical would want to use Mir, what reason could they possibly have to use it? But it seems you go to great lengths to avoid answering this question. If you don't have an answer, just say so, and we can assign your Mir-evangelism to irrational fanboyism.

Considering The teams surrounding Kubuntu have gone into the 'cave' regarding innovation and supporting forward projects like Mir
...
Btw I mean what I say.

Seems to me you really have some great reasons why you think KDE and others should support Mir. You must have some really good information about why Mir suits their needs better than Wayland. Why else would you write things like that? Tell us the reasons. Why should KDE use Mir instead of Wayland? Why is Mir a better match for them (or anyone)?

[z0id]

Mir solves this problem since it uses Android drivers, but Kubuntu teams have demonised Mir and have locked down to Wayland, therefore what hope is there. Some claim Wayland and the Sailfish project show promise of Android leanings, but no where near the vision of Canonical's Mir which is a fundamental to them to use Android drivers.

Anyway it's a matter of opinion. You can pass my comments by.

Mir gained Android drivers support by using Jolla's library libhybris, which Jolla is using for Wayland with Android drivers.

[erendorn]

please dee, just put him on your ignore list, if you quote him I can still see his posts.

[e8hffff]

So it was already working before Canonical took and ran with it - it's another part why Mir couldn't exist without Wayland. Now would you care to address the rest of my post? I'm really curious to know your answer. Why are you avoiding it?

As far as I know it was only doing basics, like plain video wrapping and maybe touch. I'm no expert, so I'm only going by what I recall and I haven't been following the scene completely. Like I haven't read before what you quoted.

Canonical said they had to bring abilities into their court as the solutions out there didn't suit their direction [paraphrasing]. The reason why they dropped Wayland and coded for their own needs.

[dee.]

1. As far as I know Carsten Monk library only did minimal wrapping.
2. Canonical looked to make their own wrapper but worked with libhyris as they coded their own (happen stance)
3. They never changed the name of libhybris
4. When Canonical come out with the code they were currently at [Canonical without malice], Carsten declared them thieves even though it was open source.
5. The code is open to public and far more embellished.

I was incorrect to say Canonical never forked libhyris as technically it is forking.

According to Munk

Open sourcing worked quite well - a small group of people got together, tested it, improved it, got it running on a lot of multiple chipsets - thanks to OpenWebOS, Florian Haenel (heeen), Thomas Perl (thp), Simon Busch (morphis) and others. It turned the project from a late night hacking project into a viable solution for building device OS'es on top of. Or even running Android NDK applications using.

Earlier this year however, I discovered that a well-known company had taken the code - disappeared underground with it for several months, improved upon it, utilized the capability in their advertisements and demos and in the end posted the code utilizing their own source control system, detached from any state of that of the upstream project's. Even to the extent some posters around the web thought libhybris was done by that company itself.

So it was already working before Canonical took and ran with it - it's another part why Mir couldn't exist without Wayland.

Now would you care to address the rest of my post? I'm really curious to know your answer. Why are you avoiding it?

[e8hffff]

Oh please. You're being very silly now. [/b]

You quoted something I edited out.

Canonical didn't fill into their own flesh on a skeleton, they built much of the skeleton and filled it too [in this analogy]. ...So to call them thieves which was the intended context of the original reply, is erroneous.

The question of Wayland using the new libhybris, is for future scrutiny. I hope they do use it, but the direction of Mir seems to be more precise on using Android drivers.

[e8hffff]

Do you realize that libhybris, which enables Mir to use Android drivers, was originally developed by Jolla, for Wayland, in order to use Android drivers in Wayland, and is still used by Jolla in order to use Android drivers in Wayland? So not only is it untrue that Mir has an advantage in this regard, the only reason Mir can even use Android drivers is because of Wayland. But then, the entire Mir couldn't exist without all the work done by Wayland developers..

1. As far as I know Carsten Monk library only did minimal wrapping.
2. Canonical looked to make their own wrapper but worked with libhyris as they coded their own (happen stance)
3. They never changed the name of libhybris
4. When Canonical come out with the code they were currently at [Canonical without malice], Carsten declared them thieves even though it was open source.
5. The code is open to public and far more embellished.

I was incorrect to say Canonical never forked libhyris as technically it is forking.

[dee.]

There's no proof of that. Carsten Munk just guessed Canonical forked his code and months later released a bigger coded project than his.

Oh please. You're being very silly now.

If you programme, methods and structures do end up looking similar when attempting to tackle the same task.

If someone can prove that the coding was copied verbatim in parts or it's declared a fork, then it's only a guess.

If you "programme", you can actually tell when code is copied from other code. Canonical admitted it, they tried to pass it off as their own, they now contribute to the original.

Libhybris isn't the only part they swiped, btw - XMir was copied pretty much 1:1 from XWayland, then adapted to talk to Mir instead of the Wayland protocol. Let me be very clear about this: Mir would not be here, it would not be possible, without Wayland - both because of code written for Wayland, and because of the groundwork and plumbing done by Wayland devs and others to make the rest of the graphics stack ready for a modern display system.

Now, maybe you'd like to address the part of my post you conveniently ignored, you know... everything below the first paragraph that you quoted? Because I'd really like to know your answer to this question that I asked in my previous post:

So tell me, why exactly should KDE, Jolla or anyone other than Canonical bother with Mir? Why, when they already have a much better alternative available (Wayland) that suits their needs much better? What possible reasoning could you have for wanting others to use Mir besides blind fanboyism? Maybe you have some new inside info that no one else knows? Please share, I'm listening.

[e8hffff]

Canonical is now CONTRIBUTING to libhybris. Carsten Munk's quote from this post:

Yes I know that and libhybris is on launchpad. I probably didn't write the post well.

The point I was trying to get across was early on Carsten bitched that his project was stolen but there was no proof Canonical planned to ride his library. Since then they have stayed with it and added to the public code. Some people continue to define Canonical as thieves when they could have simply rewrote the code in their style.

[panda84]

Plasma Active is a no go for being in the hands of anyone who isn't a KDE enthusiast. Aaron Seigo is basically making a tablet for himself and a few friends.

Aaron Seigo is not developing the tablet. The Community interest company Rhombus Tech is.

And the same hardware is being used for other projects:

29 Apr 2013: First sample pictures

Last week Aaron's samples arrived, ahead of schedule. It's taken another week for two more to be shipped, and here they are! Photos below show them in an Amphenol PCMCIA socket, which is planned to be used in the 7in Flying Squirrel Tablet and many other products after that, including the 5in Hand-held Games Console and the Open Hardware Laptop. The A10 CPU Card can also take a Dual-Core ARM Cortex A7 Allwinner A20 processor with no modifications to the PCB.

Moreover the tablet will be fully open (open kernel, open schematics, as many open hardware drivers as possible); so I think it's a big improvement for all the embedded Free Software community, not just for the KDE community.