From VirtualGL's point of view, there are two issues with the X server that is running on your Raspberry Pi:
-- It needs a GLX extension. You can see from the output of xdpyinfo that it currently lacks one. -- It appears to be currently running with a depth of 16. It needs to be running with a depth of 24. Those settings are generally changed in xorg.conf, but more important than the presence of a GLX extension is the presence of a GPU for it to leverage. I am not familiar with what GPU is in Raspberry Pi and how to configure the X server to take advantage of it. What I can tell you is that, before you're going to be able to successfully use VGL, the output of xdpyinfo will need to show the presence of a GLX extension on display :0 with "depth of the root window" = 24 or 32, and the output of '/opt/VirtualGL/bin/glxinfo -display :0 -c' will need to indicate the presence of Pbuffer support (refer to the VirtualGL User's Guide) as well as the presence of accelerated 3D drivers (i.e. the GLX vendor strings and the OpenGL renderer string should not have the word "software" or "Mesa" in them.) On 4/13/14 7:57 AM, George Profenza wrote: > Thank you again for the detailed answer. > > Unfortunately, since I am not very experienced I am hoping you can still > help with a few (hopefully) simple questions. > You mentioned I should " get a "3D X server" up and running just like > you would when using > VirtualGL with a "regular" PC. " > I'm not 100% what you meant. Had a quick look at what x11 packages are > available and I can easily install these: > x11-apps x11proto-kb-dev x11proto-xf86dri-dev > x11-common x11proto-print-dev x11proto-xf86misc-dev > x11proto-bigreqs-dev x11proto-randr-dev x11proto-xf86vidmode-dev > x11proto-composite-dev x11proto-record-dev x11proto-xinerama-dev > x11proto-core-dev x11proto-render-dev x11-session-utils > x11proto-damage-dev x11proto-resource-dev x11-utils > x11proto-dmx-dev x11proto-scrnsaver-dev x11vnc > x11proto-dri2-dev x11proto-video-dev x11vnc-data > x11proto-fixes-dev x11proto-xcmisc-dev x11-xfs-utils > x11proto-fonts-dev x11proto-xext-dev x11-xkb-utils > x11proto-gl-dev x11proto-xf86bigfont-dev x11-xserver-utils > x11proto-input-dev x11proto-xf86dga-dev > > I've installed the gl-dev, dri2-dev,dmx-dev packages and also > mesa-common-dev and mesa-utils > Also tried using some of the info tools but it doesn't look great: > " > pi@picam2 ~ $ glxinfo > name of display: :0.0 > Error: couldn't find RGB GLX visual or fbconfig > > pi@picam2 ~ $ glxgears > Error: couldn't get an RGB, Double-buffered visual > pi@picam2 ~ $ glxdemo > Error: couldn't get an RGB, Double-buffered visual > pi@picam2 ~ $ glxheads > glxheads: exercise multiple GLX connections (any key = exit) > Usage: > glxheads xdisplayname ... > Example: > glxheads :0 mars:0 venus:1 > Error on display :0.0 - Unable to find RGB, double-buffered visual > pi@picam2 ~ $ glxheads :0 > Error on display :0 - Unable to find RGB, double-buffered visual > pi@picam2 ~ $ glxheads :0.0 > Error on display :0.0 - Unable to find RGB, double-buffered visual > pi@picam2 ~ $ > " > > I've going through the manual and got a bit stuck at "VGL Transport with > X11 Forwarding". > I've previously "granted access to the 3D server" > using /etc/init.d/lightdm stop, running vglserver_config (with options > n,n,n), restarted the display manager > and got this output from xdpyinfo: > " > pi@picam2 /opt/VirtualGL/bin $ xdpyinfo -display :0 > name of display: :0 > version number: 11.0 > vendor string: The X.Org Foundation > vendor release number: 11204000 > X.Org version: 1.12.4 > maximum request size: 16777212 bytes > motion buffer size: 256 > bitmap unit, bit order, padding: 32, LSBFirst, 32 > image byte order: LSBFirst > number of supported pixmap formats: 7 > supported pixmap formats: > depth 1, bits_per_pixel 1, scanline_pad 32 > depth 4, bits_per_pixel 8, scanline_pad 32 > depth 8, bits_per_pixel 8, scanline_pad 32 > depth 15, bits_per_pixel 16, scanline_pad 32 > depth 16, bits_per_pixel 16, scanline_pad 32 > depth 24, bits_per_pixel 32, scanline_pad 32 > depth 32, bits_per_pixel 32, scanline_pad 32 > keycode range: minimum 8, maximum 255 > focus: window 0x2000005, revert to Parent > number of extensions: 25 > BIG-REQUESTS > Composite > DAMAGE > DOUBLE-BUFFER > DPMS > DRI2 > Generic Event Extension > MIT-SCREEN-SAVER > MIT-SHM > RANDR > RECORD > RENDER > SECURITY > SHAPE > SYNC > X-Resource > XC-MISC > XFIXES > XFree86-DGA > XFree86-VidModeExtension > XINERAMA > XInputExtension > XKEYBOARD > XTEST > XVideo > default screen number: 0 > number of screens: 1 > > screen #0: > dimensions: 656x512 pixels (174x135 millimeters) > resolution: 96x96 dots per inch > depths (7): 16, 1, 4, 8, 15, 24, 32 > root window id: 0x43 > depth of root window: 16 planes > number of colormaps: minimum 1, maximum 1 > default colormap: 0x20 > default number of colormap cells: 64 > preallocated pixels: black 0, white 65535 > options: backing-store NO, save-unders NO > largest cursor: 656x512 > current input event mask: 0x7a003c > ButtonPressMask ButtonReleaseMask EnterWindowMask > LeaveWindowMask StructureNotifyMask > SubstructureNotifyMask > SubstructureRedirectMask FocusChangeMask PropertyChangeMask > number of visuals: 2 > default visual id: 0x21 > visual: > visual id: 0x21 > class: TrueColor > depth: 16 planes > available colormap entries: 64 per subfield > red, green, blue masks: 0xf800, 0x7e0, 0x1f > significant bits in color specification: 8 bits > visual: > visual id: 0x41 > class: TrueColor > depth: 32 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits > " > Then I tried to connect and run glxspheres > " > pi@picam2 /opt/VirtualGL/bin $ ./vglconnect pi@picam2.local > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > vglclient is already running on this X display and accepting unencrypted > connections on port 4242. > > pi@picam2.local's password: > Linux picam2 3.10.36+ #665 PREEMPT Wed Apr 9 15:01:53 BST 2014 armv6l > > The programs included with the Debian GNU/Linux system are free software; > the exact distribution terms for each program are described in the > individual files in /usr/share/doc/*/copyright. > > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent > permitted by applicable law. > Last login: Sun Apr 13 13:38:32 2014 from 192.168.0.14 > pi@picam2 /opt/VirtualGL/bin $ ./vglrun ./glxspheres > [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to > [VGL] 192.168.0.14, the IP address of your SSh client. > Polygons in scene: 62464 > ERROR (603): Could not obtain RGB visual with requested properties > pi@picam2 /opt/VirtualGL/bin $ ./vglconnect -x pi@picam2.local > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > vglclient is already running on this X display and accepting unencrypted > connections on port 4242. > > mktemp: failed to create file via template `vglconnect.XXXXXX': > Permission denied > ^C > pi@picam2 /opt/VirtualGL/bin $ sudo ./vglconnect -x pi@picam2.local > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > X11 connection rejected because of wrong authentication. > start-- 534: Could not open display > [VGL] ERROR: vglclient failed to execute. > > " > > Also, if it helps, here's the full ldd info on glxspheres: > " > pi@picam2 /opt/VirtualGL/bin $ ldd glxspheres > /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6f30000) > libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6ebb000) > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6da7000) > libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6d4b000) > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6cda000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6bab000) > libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0xb6b84000) > libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6b6e000) > libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6b64000) > libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6b57000) > libX11-xcb.so.1 => /usr/lib/arm-linux-gnueabihf/libX11-xcb.so.1 (0xb6b4d000) > libxcb-glx.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-glx.so.0 (0xb6b34000) > libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6b15000) > libXxf86vm.so.1 => /usr/lib/arm-linux-gnueabihf/libXxf86vm.so.1 (0xb6b08000) > libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb6af6000) > libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ad6000) > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6acb000) > libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb69fe000) > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb69d6000) > /lib/ld-linux-armhf.so.3 (0xb6f3e000) > libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb69cc000) > libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb69bf000) > librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb69b0000) > " > > At this point I am bit lost. Your suggestion of trying "to test > VirtualGL as-is and verify that it works on that platform." sounds good. > Can you please advise how I can continue with that ? > > Thank you again for all your support, > George > > > On Sun, Apr 6, 2014 at 5:38 PM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> wrote: > > On 4/6/14 5:06 AM, George Profenza wrote: > > 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 really don't know anything about Raspberry Pi, but if it has libX11, > then apparently it does support a regular X server. Also, if you're > getting that error message, then apparently it supports GLX as well > (otherwise, GLXspheres wouldn't even run.) I suspect that EGL may be > implemented as a wrapper to GLX, which means that you're going to have > to get a "3D X server" up and running just like you would when using > VirtualGL with a "regular" PC. This would at least allow you to test > VirtualGL as-is and verify that it works on that platform. > > There is a remote chance that EGL is implemented as a GLX wrapper and > that the implementation is done in such a way that EGL applications > could be made to work with VirtualGL as-is. Basically, this would be > the case if the EGL API was in a separate library that made GLX calls > into libGL. I suspect, however, that that's not how it works. It's > more likely that the EGL calls are exposed in libGL itself, in which > case VirtualGL would have to specifically interpose those calls. And > GLXspheres and the other "toy" applications in the VGL source would need > to be ported to EGL. > > The other aspect of this is the windowing system. VirtualGL's basic job > is to split OpenGL and X11 rendering. VirtualGL redirects the OpenGL > rendering to a "local" X server (the "3D X server") that is attached to > a GPU. It then reads back the rendered 3D pixels at the appropriate > time and uses 2D drawing commands to composite those pixels back into > the appropriate X window, which is displayed to a remote X server or X > proxy (the "2D X server".) Meanwhile, the other X11 drawing commands > from the application go directly to the 2D X server. > > Thus, it goes without saying that, if an OpenGL ES application is not > using X windows as a means of drawing its GUI, then VirtualGL will not > be applicable. This doesn't mean that the application has to directly > call X windows. It could be using a toolkit, such as GTK or Qt, that > calls X windows "behind the scenes", but ultimately, there has to be > some underlying communication between the application and libX11 in > order for VirtualGL to work-- as well as VNC, since VNC is a virtual X > server. > > > > > I'm guessing by "science fair" you mean too localized > > Yes. The funding aspect is a sort of filter. If someone wants a > feature badly enough to pay for it, then the feature usually tends to be > broadly applicable. It's quite often the case that one organization > will pay me to implement a feature, and another organization will start > using the feature and pay me for follow-up work down the road. It is > extremely rare that an organization will pay for a feature that is only > narrowly applicable. > > VirtualGL does have a "general fund" that pays for 200 hours/year of my > labor, but I have to be judicious with that, since it has to cover any > time I spend doing releases and answering e-mails on the mailing lists > and doing code cleanup, etc. I have, on occasion, used that fund to pay > for new feature implementations, but it really has to be something that > is very compelling and something that I feel will move the project > forward. > > > > 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. > > Crowd funding might be useful. It would definitely be a good indicator > of whether enough people are interested in this to pay for its > implementation. I suspect, however, that this feature is not broadly > applicable enough to attract the kind of money that would pay for my > labor to implement it. The problem, as above, is that implementing > OpenGL ES support in VGL would only allow a very narrow class of OpenGL > ES applications-- those that use X11 to do their drawing-- to be > supported. Most mobile applications aren't going to fall into that > category. > > > > > > Thanks again, > > George > > > > > > > > On Sun, Apr 6, 2014 at 7:55 AM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net> > > <mailto:dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>>> wrote: > > > > > > > > On Apr 5, 2014, at 1:14 PM, George Profenza <orgi...@gmail.com > <mailto:orgi...@gmail.com> > > <mailto:orgi...@gmail.com <mailto: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 > <mailto:dcomman...@users.sourceforge.net> > >> <mailto:dcomman...@users.sourceforge.net > <mailto: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 <mailto:orgi...@gmail.com> > <mailto:orgi...@gmail.com <mailto: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 > <mailto:VirtualGL-Users@lists.sourceforge.net> > >> <mailto:VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net>> > >> >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> VirtualGL-Users mailing list > >>VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > >> <mailto:VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net>> > >>https://lists.sourceforge.net/lists/listinfo/virtualgl-users > >> > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> VirtualGL-Users mailing list > >>VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > >> <mailto:VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net>> > >>https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > VirtualGL-Users mailing list > >VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > > <mailto:VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net>> > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > VirtualGL-Users mailing list > >VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
