Hi. I've looked further into this. I unfortunately don't have the resources available to try and get KDE 4 up and running. I actually did spend a few hours trying to get KDE 3.5 up and running with compiz in TigerVNC to see if I could reproduce the issue. It failed because TigerVNC lacks the X Keyboard extension. Then I tried to launch compiz in VirtualGL with just a "dumb" local X server (one without the window manager started.) I could launch compiz in this X server fine, but it failed with VirtualGL. The failure was different from what you observed. In my case, it just simply wouldn't get past XOpenDisplay().
If you can come up with a small test program that demonstrates the GLX_BIND_TO_TEXTURE_*_EXT failure, that's going to be the most expedient way to solve this. On 4/13/10 9:02 AM, Александр Кириллов wrote: > By the way, I've disabled some checks in KDE4 and it is now able to > render itself in OpenGL mode, > but it shows only gray background for windows (a single rectangle) and > black background for > message boxes (also a rectangle). >> Visuals are not the same as FB configs in VirtualGL. Visuals are on the >> client and FB configs are on the server. Thus, a visual will always >> have a 24-bit depth even though the FB config used to create the Pbuffer >> may have a 32-bit depth. >> >> Thus, I don't think that's the cause of the issue. If it's looking for >> a visual with GLX_BIND_TO_TEXTURE_RGBA_EXT, then that may be the cause. >> How did you determine that it is looking for such a visual? Please be >> as verbose as possible. Don't just say "from debugging", as this does >> not tell me how you debugged the problem. >> >> On 4/11/10 6:49 PM, Александр Кириллов wrote: >> >>> Well, a 32-bit FB config supports rendering alpha channel (24-bit FB >>> config has 0 bits for alpha and 32-bit has 8 bits for alpha). >>> Yes, glxinfo repots this and also the debugging - the depth field of a >>> visual equals 24. >>> >>>> I'm not sure I understand what you mean about 24-bit vs. 32-bit FB >>>> configs. And what do you mean by "VirtualGL tells me that those are >>>> 24-bit configs"? Are you running /opt/VirtualGL/bin/glxinfo -c to get >>>> this information? >>>> >>>> On 4/10/10 3:01 PM, Александр Кириллов wrote: >>>> >>>> >>>>> Hello! >>>>> >>>>> I'm trying to run KDE4 over VNC with TigerVNC and VirtualGL, but it >>>>> didn't work out of the box. >>>>> I used a debugger and found out that KDE4 cannot find a suitable >>>>> GLXFBConfig - 32-bit with GLX_BIND_TO_TEXTURE_RGBA_EXT (or the same with >>>>> RGB instead of RGBA) support. >>>>> On the host system there are plenty of such GLXFBConfigs, but VirtualGL >>>>> tells me that those are 24-bit configs (I've compared them by number). >>>>> Can you please suggest me what to do in order to help VirtualGL find a >>>>> suitable framebuffer configuration? >>>>> >>>>> Best regards, >>>>> Alexander Kirillov >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Download Intel® Parallel Studio Eval >>>>> Try the new software tools for yourself. Speed compiling, find bugs >>>>> proactively, and fine-tune applications for parallel performance. >>>>> See why Intel Parallel Studio got high marks during beta. >>>>> http://p.sf.net/sfu/intel-sw-dev >>>>> _______________________________________________ >>>>> VirtualGL-Users mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> VirtualGL-Users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> VirtualGL-Users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
