Wayland and X.org problem : Why not following the Android Solution ?

https://www.reddit.com/r/linux/comments/8f9o5y/wayland_and_xorg_problem_why_not_following_the/

Q:

I'm not a linux expert , but no one can deny that a lot of distributions and DE have some issues to replace X.org.

And i Know that Android ( and even chrome OS ) don't use X.org and have great performances , so why GNU/Linux distributions don't go for the same solutions ?

i'm looking for a technical explanation please.

Thanks

A:

Android does things very similarly to Wayland, but the Android graphics stack is pretty tightly coupled to the rest of Android, and it doesn't do some things that are rather useful in desktop/server environments. So Wayland is basically "the Android way", adjusted for desktop use cases.

----------

KWin maintainer speaking: I implemented both the Wayland platform plugin to interface with Linux's DRM subsystem and with Android's hwcomposer.

The main issue with Android's stack is that it is not libc compatible. You need very ugly solutions like libhybris (see https://en.wikipedia.org/wiki/Hybris_(software) ). The hwcomposer layer is compared to DRM extremely lacking. It's lacking atomic updates, it's lacking lots of support for multiple monitors, switching resolutions etc. It's designed for smartphones with one resolution and that's something you notice.

To give you an idea on how lacking hwcomposer is: the plugin for hwcompser in KWin is 754 sloc, the drm plugin in KWin is 3846 sloc. The difference is because hwcompser just lacks features we could implement in drm.

The windowing system running on top of hwcomposer in an Android stack is called surfaceflinger and is compared to a normal windowing system like X11 or Wayland also extremely lacking. It's slowly getting support for things like multiple windows, etc.

Overall it's just not really useful for a desktop system. Starting from the libc system, going to all the details of a good system for desktops.

--------------