Thanks for your help. I managed to hack something and have a basic ut_renderer 
working on Linux. The android GL implementation can connect to it ok.

However, I had to patch a lot of stuff related to glXGetFBConfigs etc. to get 
this to work. I am afraid the surface is not what android expects it to be so 
the colors etc. are all very weird. I wanted to ask you if you have to tweak 
something in X to support visuals which android would like or does the 
translation take care of it? Did you use any specific version/distribution of X?

Also does the ut_renderer (or anything similar) work on Windows yet?

I understand this is under heavy development, but at the minimum I wanted to 
get to the stage of the demo you showed at IO. I hope I can get there with the 
sources which are in the tree.

Suman

On 21-May-2011, at 2:51 AM, David Turner wrote:

> 
> 
> On Thu, May 19, 2011 at 7:45 PM, Suman Saraf <sumansa...@gmail.com> wrote:
> Thanks David.
> 
> I checked out the latest code and have started to fiddle with it. I am trying 
> to run this on x86 inside VirtualBox.
> 
> I have a few questions and would be glad if you could help:
> 
> 1. I built everything inside shared and system and 
> tests/gles_android_wrapper. That produced the EGL, GLES_v1 and GLES_v2 
> libraries. I copied these to my device along with the egl.cfg and 
> gles_emul.cfg
> 
> sounds about right.
>  
> 2. do I need to build gralloc also? I did build it and planted it in 
> system/lib/gralloc.default.so; overwriting the gralloc.default.so for the 
> software only renderer.
> 
> nope, this doesn't work yet.
>  
> 3. now I need to build a renderer application which can render it remotely. I 
> tried building host/renderer on Linux. Ideally I want to build this on 
> Windows? Is it possible?
> the resulting emulator_renderer binary (on Linux) failed to initialize 
> frame-buffer because of unsupported EGL_RENDERABLE_TYPE in eglChooseConfig.
> 
> the only one that works is ut_renderer for now. And usage is a bit specific. 
> forget about emulator_renderer for now.
>  
> To reiterate, I ideally want to build the emulator_renderer on Windows. Is it 
> possible? Is there an alternate way to render this remotely on Windows? How?
> 
> Am I completely off track or is this really the way to get this thing to run?
> 
> 
> This work is in progress and very very experimental. I would like to ask you 
> to be patient before trying to use it. usage instructions are going to change 
> a lot in the coming weeks so I prefer not to document these officially.
> 
> Thanks for your comprehension
> 
> - David
> 
>  
> Thanks
> Suman
> 
> 
> On 16-May-2011, at 9:09 PM, David Turner wrote:
> 
>> 
>> 
>> On Fri, May 13, 2011 at 3:58 PM, Suman Saraf <sumansa...@gmail.com> wrote:
>> > Hello,
>> >
>> > I just saw this demo on youtube. Looks very cool. I have been working 
>> > independently on the same problem trying to remote GL calls to the host. 
>> > This basically means mapping EGL and GL calls to GLX/GL on Linux (which is 
>> > my host right now). I am using Chromium to pack/remote/unpack and manage 
>> > state.
>> >
>> > Does the google implementation also use Chromium?
>> >
>> Not that I know of. It's a custom wire protocol.
>> 
>> > Are there some code bits which have been checked into the AOSP tree which 
>> > I could look at?
>> >
>> Yes, look at development/tools/emulator/opengl/ (warning: work in progress)
>> 
>> > Thanks
>> > Suman
>> >
>> 
>> --
>> unsubscribe: android-porting+unsubscr...@googlegroups.com
>> website: http://groups.google.com/group/android-porting
>> 
> 
> 

-- 
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting

Reply via email to