Thank you very much for the detailed explanations and your patience. Using ldd on vglserver_config yelds:"not a dynamic executable" For the gl apps I see all the linked libraries and "libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6f21000) libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6ec5000) libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6db1000) l " I can't run the demos though (E.g. glxspheres), I get this output: " Polygons in scene: 62464 ERROR (603): Could not obtain RGB visual with requested properties "
So I guess the GL code in the sources need to be ported to GLES and it sure doesn't look simple to me :) I'm guessing by "science fair" you mean too localized, if so, that would be my case. I'm using playing with http://openframeworks.cc (an easy to use collection of c++ libraries) which has an GLES renderer, so to see the output, I need to hook up a display with the Raspberry PI. I was wondering if I the gl graphics can somehow be streamed to a vnc client and that's how I found VirtualGL. The project looks very useful. It must be pretty hard code for you being the only maintainer. I'm wondering if crowd funding would work to help with the financial support needed. My guess is OpenGL ES support would be useful for people using Raspberry PI, beagle bone,Odroid,UDOO,etc. but perhaps to smart phone game developers, but I shoould do my homework on this instead of making asssumptions. Thanks again, George On Sun, Apr 6, 2014 at 7:55 AM, DRC <dcomman...@users.sourceforge.net>wrote: > > > On Apr 5, 2014, at 1:14 PM, George Profenza <orgi...@gmail.com> wrote: > > Hi, > > I'm new to this so want to make sure I understood what you just explained > :) > > Currently, "out of the box", just compiled, as-is I won't be able to use > VirtualGL to serve an OpenGL ES window to TurboVNC, correct ? > > > Correct > > "LD_PRELOAD exists in the underlying O/S and applications are dynamically > linked with the OpenGL ES library" and - is there a quick way to test > this ? > I'm hoping the application got linked with OpenGL ES. > > > ldd {application binary} > > will tell you whether the app is dynamically linked with OpenGL ES. > Testing LD_PRELOAD is more of an advanced topic. > > > Regarding intercepting and modifying EGL calls, that would be something I > would need to modify in the VirtualGL sources ? > If so, any hints on how I could get started ? > > > Yeah, spend 8 years dealing with various OpenGL, high-performance > computing, and video streaming problems, then another 10 doing nothing but > developing remote 3D software, and the problem will seem straightforward. > :) Otherwise, it would be difficult for me to bring you up to speed on the > types of issues you are likely to encounter. > > This is why (and how) I make my living doing contract development and > consulting around this stuff. I don't earn a salary, so I rely on financial > sponsorship to keep this project afloat, and that usually takes the form of > organizations paying me to add features. I do things that way for two > reasons: (1) it allows the project to respond to the needs of various > different (and sometimes competing) organizations rather than being > co-opted for one specific organization's agenda, and (2) the expectation > that new features will usually require financial sponsorship means that > there will be a well-defined need for any new feature that goes in (thus > preventing VGL from becoming a "science fair" project.) > > I created VirtualGL from scratch more than 10 years ago. I've been the > sole maintainer of the project and have developed probably 99% of its code. > I am not trying to sound arrogant, but it's just not possible for me to > teach you or anyone else what I know, because I myself was not taught it. I > discovered how to do it on my own through years of experimentation and > research. Even if I brought someone else up to speed on this code, it would > take them twice as long to develop a feature as it would take me, and the > result would not be as good, so I'd end up having to spend my free time > cleaning up the contributed patches. I am willing to do that if the feature > is something that I feel will be broadly applicable. I don't get that sense > here, though. Without understanding more about why you're trying to bring > up VGL in this environment, I'm getting a very strong "science fair" vibe > here. > > > Thank you, > George > > > On Sat, Apr 5, 2014 at 2:20 PM, DRC <dcomman...@users.sourceforge.net>wrote: > >> Not currently. I don't know of any technical reason why it couldn't, >> assuming that LD_PRELOAD exists in the underlying O/S and applications are >> dynamically linked with the OpenGL ES library. Conceptually, it would just >> require intercepting and modifying the EGL calls in much the same way that >> we currently modify the GLX calls. Straightforward but would probably >> require a lot of testing in order to get right. >> >> > On Apr 5, 2014, at 4:01 AM, George Profenza <orgi...@gmail.com> wrote: >> > >> > Hello, >> > >> > I'm new to VirtualGL and I was wondering if I could use it on a >> Raspberry PI. >> > (arm v6 cpu with a broadcom gpu) >> > >> > I've compiled libjpeg-turbo and VirtualGL from source and ran >> vglserver_config >> > but I can't seem to get an OpenGL ES window showing up in TurboVNC. >> > Is it possible to use OpenGL ES on VirtualGL ? If so, how ? >> > >> > Thank you for your time, >> > George >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > VirtualGL-Users mailing list >> > VirtualGL-Users@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > >
------------------------------------------------------------------------------
_______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
