Why don't they just use the Android display server on Linux distributions instead of X.org or Wayland?
Why create Wayland when there is some display server on Android?
I don't think Android uses X.org, it probably has its own display server.
Phoronix: Java Bindings Come To Wayland For Android
The code to wayland-java has now been made public, which is a project that provides Java bindings to the Wayland back-end library. This Java support will be useful for Wayland support on Google's Android mobile platform...
http://www.phoronix.com/vr.php?view=MTI3MjA
Why don't they just use the Android display server on Linux distributions instead of X.org or Wayland?
Why create Wayland when there is some display server on Android?
I don't think Android uses X.org, it probably has its own display server.
I don't know very much about the internals of Android, but the SurfaceFlinger/Skia superficially resembles very much the Weston/libwayland/cairo concept.
You see, it's because not everyone is a genius like you.
Besides Flinger, being developed for smartphones can easily be extended to.. other smartphones.
And it will even work well on desktops, just like an OS can be written in JavaScript and still work (well enough to be worth bragging about it).
Sarcasm aside, Android uses a lot of half-baked but good enough solutions (the audio and graphics stacks) which over time got improved that they seem decent enough for certain scenarios, but they can be better. Like ext2 has been improved up to ext4 and supports a lot of features like punch holes - but btrfs is still the future. Wayland is way better from the get go, more versatile and not designed with only smartphones in mind.
Last edited by mark45; 01-10-2013 at 08:56 AM.
But it would be more useful to add a Flinger/skia backend for GTK than trying to replace the whole android stack.
I'd rather see the linux desktop and android converge more for more compatibility (for thinks like ubuntu on android). As much as I hate Windows 8, it's leading the way for platform integration.
You're missing the point.
Wayland is written for Linux. The point of this is to test it out on Android, to see how easy it is to port, to make sure there are no hidden surprises, etc.
Porting GTK to surfaceflinger doesn't help out Wayland at all, and there are tons of reasons linux distros don't want to just dump X for surfaceflinger.
That's definitely a cool idea. You can send your patches to the gtk devel ml =)
As far as I understand it, X.org suffering from a split personality disorder:
1. It has the classic, client-server framebuffer magic, and on the other end;
2. To modernize the Linux desktop with compoziting and whatnot, X turns more to local rendering code paths.
Wayland basically cuts the X.org architecture from the old framebuffer networking down to what X.org itself is build on, and puts a modern window management sauce on top.
If Wayland is then ported to Android, which is a good use case for stripped down, modern and local rendering, it also uses the modern Linux drivers. That means that if it turns out to work well with Android apps, things like the MK2 Android can be appear on small, yet common hardware devices, so for example you could carry a more standard Linuxy home theatre PC in your pocket and still make use from Android apps.
TL;DR: clean, standard Linux kernel implementations, thus less fragmentation between 'desktop Linux' and Android Linux.
Wayland's lighter & built with more in mind.
versus GTK on Android:
- Wayland's worse for porting apps to Android (short term)
- Wayland's better if picked-up by Android (medium term)
- Wayland's best on non-Java Linux phones (long term) which could be tested soon in partial-Android environments
Adding thru-JNI costs to native apps on Android will guarantee they're always second-class (ref Firefox OS's discussion vs Android). A common base penalizes either app type the least.