drm_hwcomposer: Allowing Mainline Linux Graphics Drivers To Work On Android

[cb88]

android does not run on smaller systems

It's a pointless argument.... the libc is either wastefully bloated or not, its either doing a good job of closing attack vectors... or it's not. MUSL is at least a better alternative full libc than glibc.... bionic is too cut down for normal usage, in that Sense android apps are not normal Linux apps.

[GI_Jack]

glibc is just not a good libc for embedded and smaller systems. You can tell by how nobody is using it there.

note entirely true. Meego, maemo, sailfish all used glibc. Not only that, meego and maemo ran X, Qt, and GTK, while sailfish I believe is wayland, but retains Qt and GTK. Maemo 5, as shipped on the n900, was close enough to debian that you could install and run Debian 5 armel packages unmolested and expect them to work. bash was the default shell on the N900 which came with XTerm, and GNU core utils was officially supported.

You could run the entirety of the GNU userland on maemo 5 if you so chose.

Samsung's Tizen also runs Wayland, GNU, the enlightenment libraries.

Android does not use the typical UNIX usage model, and opts for per-app permissions which suit mobile far better, as phones generally have one users, and many apps from often untrusted, or semi-trusted sources. Very much a seperate use case. The state of Linux graphics when android started was also somewhat poor.

[microcode]

even? http://en.cppreference.com/w/cpp/numeric/random

Mersenne twister and LCG are wildly outdated and flawed for high volume or security-critical random, and considering that this interface requires you to seed the generators yourself, all the worse. I recommend a talk given by Theo de Raadt at Hackfest 2014 for some idea of the lengths that we have to go to to get good random.

[artyom.h31]

For what it's worth, Android's graphics stack was ahead of the curve on many things.

If so, why Linux desktop developers haven't just borrowed Android technologies?

[oiaohm]

If so, why Linux desktop developers haven't just borrowed Android technologies?

Not that straight forwards. Just because the Android graphics stack is way ahead of the curve in particular areas does not mean there were not other areas where it was lacking. So its more of a process of integrate what Android does better without breaking what the existing stack did well.

[unixfan2001]

If so, why Linux desktop developers haven't just borrowed Android technologies?

Ummm.

Because they have?

https://en.wikipedia.org/wiki/Hybris_(software)

[oiaohm]

If so, why Linux desktop developers haven't just borrowed Android technologies?

The answer is no that does not work. Why Hybris is kind of a long term dead end. Android graphic stack has been more advanced on some areas but it also been extremely poor in others.

You have to remember most desktop applications are designed around the idea of having Opengl full not the Opengl ES cut down versions that android ships with. This is just the start of many differences.

The only option has been to look at what android has done and integrate the best features back into the DRI/DRM stack.

[oiaohm]

If so, why Linux desktop developers haven't just borrowed Android technologies?

Does not work that way. Linux Desktop applications mostly want full Opengl not Opengl ES android uses. This is the start of many key differences.

So the only correct way forwards was integrate the features from Android into the DRM/DRI stack. The most feature containing graphics stack is the graphics stack the Linux Desktop uses not the Android one. The Android graphic stack has contained a few features the Linux has lacked.

So Libhybris/hybris is a very limited work around.

[droidhacker]

android does not run on smaller systems

That's only because the hardware has advanced *considerably* in the time since the footing was being poured over a DECADE ago, allowing the software to grow such that it can no longer run on what it used to be able to. Go take a quick peak at the hardware that Android was introduced with (in late 2008)...

ARMv6 single core 528 MHz CPU downclocked to 384 MHz.
192 MB RAM, of which only 96 MB was addressable by Linux, the rest was allocated to the RIL and GPU.
256 MB flash storage, which was for both the RO system, **AND** RW userdata.


Now then the question may be why they haven't switched over to glibc since then, and there are a number of answers to that;
1) Its lots of work with little reward.
2) Some have mentioned security considerations.
3) The license on glibc is LGPL, which is scary for some vendors.

[droidhacker]

@Collabora: How about some instructions on building AOSP+drm_hwcomposer+freedreno for that DB410c? Its all nice to talk about it, but we could really use some actually description of what needs to be done to make it happen in the real world.