Android-x86, drm, drm_gralloc and co

[Chih-Wei Huang]

Hi Emil:
Glad to hear devs from upstream.
I cc the email to android-x86 list so more people can follow.

Hi Chih-Wei,
I've had a go at the Android-x86 recently in terms of being capable to
correctly build (and at a later stage run) the latest graphics stack (mesa and
libdrm).
I've already cleaned up some of Paulo's mesa patches for review + just got out
the initial libdrm android build support. Then I felt "inspired" at the way
drm_gralloc is designed and build + the lack of canonical site/repo :'(

drm_gralloc was mainly designed and implemented
by Chia-I Wu (olv) who is also a mesa developer.
Unfortunately he is too busy to improve it now.

I just tried my best to maintain it to work with
the latest android. But I'm not the expert of graphics stack.
I am hardly to improve or add more features.
Some features I hope to add include
* support more gpus (at least nouveau and vmwgfx)
* support multiple monitors
I really hope developers from upstream can help us.

Would you mind if I ask you a few questions on the topic ? I've already been
into drm + mesa quite a bit so hopefully these won't be too noobish :)
- Is there any particular reason behind the "forks" of the three projects wrt
Android-ia ? AFAICS the Intel guys occasionally pull some of your patches in,
yet I feel that a lot of the work gets duplicated :\

It's incorrect to said we forked from android-ia.
Conversely we are the original.
Android-x86 started from 2009 which is
the earliest date the mesa android porting began.
(see the git log in the donut-x86 branch of mesa)
drm_gralloc was introduced since 2011 for
android 2.3 (gingerbread).
On the other hand, Intel launched android-ia since 2012,
3 years later after we began the drm/mesa porting.
At first Intel copied and forked our repos
and added changes for Intel chips.
Some of the changes are useful for us
so I cherry-picked them to our repos.
(but sometimes they broke non-Intel gpus that made us unhappy)
Unfortunately the latest android-ia (kitkat porting) doesn't use
drm_gralloc and mesa anymore. They switched to closed source
binaries now.

I don't know why Intel forked from us.
Probably because they are big Intel who
despise our little project.

- Android-ia has libpciaccess which allows drm_intel_get_aperture_sizes
(libdrm-intel) to work as expected. Are there any plans of following their
example in Android-x86 ?

I saw no one really uses that api in android so I just disabled for simplicity.
If I remember correctly, I've traced Intel's libpciaccess porting
and found it was broken.
Anyway, if someone can show the api is useful to us,
I'm happy to add it back.

- Is there a link where I can find out more about the difference in bionic's
mman vs mman64 ? I'm looking for a cleaner fix that is to land in upstream libdrm.

I think you meant mmap and mmap64?

Android is a 32-bit OS (at least before and include kitkat).
The off_t is defined to be 32-bit in bionic.
That means mmap can only handle 32-bit offset.
But we really need 64-bit offset in x86.
So a 64-bit version (using off64_t) mmap64 was introduced to bionic.
This is an api added by Intel and now formally merged
into the aosp master branch.
(before that we used a more hacking way to workaround it)

I'm not sure what way is cleaner to be upstreamed.
The simplest way I can guess is to use ifdef like

#ifdef ANDROID
// use mmap64
#else
// use mmap
#endif

- Why did you nuke the HAL 5551 and 4444 pixelformats with drm_gralloc commit
a8eb27db697d3be48936ccb0ace9fb2a7a7e3109. The commit message is a bit shy.

Because their definitions were removed from kitkat tree (by Google).
The commit message was also copied from Google's
(commit 6bac41f in system/core and c2414bb in frameworks/native)
I can't explain more because I don't know why
they were removed, either.

Thanks for helping out

[Christopher Price]

So, I want to go into one point here. I have to very clearly state that my
views are my own. I had thought much of what I will go into, was understood
already.

The assertion that Intel "despises" Android-x86.org, is false.

I personally asked about this. Here is what I asked for the okay to share
long ago (years ago, literally):

* One Intel employee made some remarks when Android-x86.org was launched,
that were unfortunate.
* That employee's views were picked up by the press.
* Those views do not reflect Intel's view of Android-x86.org.

I don't speak for Intel - but I have never once, ever, heard a negative
remark towards the mission of Android-x86.org in any conversation I've ever
had with them. Not one.

*Intel did make a statement about Android-x86.org saying, essentially, the
same thing on 01.org. You can go to the Android-IA
<http://01.org/android-ia> FAQ and read it for yourself.*

Now, for my own opinion - Android-x86.org is important and distinct. It
provides a totally-open-source option that supports hardware for which no
company could create a business case for. That's not to say it cannot
sustain new hardware, but it works for devices that you just can't make a
business case for shooting for - like a first-generation netbook, for
example. Even in terms of supporting old Android versions - for example,
Android 4.0 and 4.1 - that work much better than Windows XP on a first-gen
netbook. That's a good thing for the ecosystem. It's a good thing for the
developing world.

Things like what I'm doing, speaking personally now, are about choice.
There should be closed and open source choices in the Android ecosystem.
Things like Android-x86.org help me go and make the case that dependencies
that we use in our work should be open source.

And, while you haven't seen much from my team in terms of shipping code, I
can tell you that code has been opened up already by making those cases
inside these big companies. It does matter, and yes, Android-x86.org
matters.

*This morning is a bit important for me personally. We're shipping our
first seeds of Console OS to industry partners, today. That would not have
happened without Android-x86.org pushing the industry in the right
direction.*

When I make a case that something is a problem, it is not to undermine
Android-x86.org, it's to make sure Android-x86.org stays awesome doing what
it's mission is, and has been since its outset - a totally-open AOSP port
for generic x86. I committed to opening up Console OS for what we can today
- its AOSP components, specifically so that such code can make its way
upstream to Android-x86.org.

Please do not assume individual technical decisions, by me, my team, or
anyone else, constitutes scorn.

Christopher Price
ConsoleOS.com

Post by Chih-Wei Huang
I don't know why Intel forked from us.
Probably because they are big Intel who
despise our little project.
--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Chih-Wei Huang]

Post by Chih-Wei Huang
I just tried my best to maintain it to work with
the latest android. But I'm not the expert of graphics stack.
I am hardly to improve or add more features.
Some features I hope to add include
* support more gpus (at least nouveau and vmwgfx)
* support multiple monitors
I really hope developers from upstream can help us.

I'm not sure how many people having the time/interest/knowledge can help here.
The lack of canonical repo+site I feel is somewhat disturbing. Perhaps we get
fd.o admins to add mesa/drm_gralloc along side mesa/drm and mesa/mesa? This
way people already working on drm+mesa have one less obstacle to climb if/when
they want to contribute.

Sounds like a good idea.
Please help to set it up.
Thanks a lot!