Re: [VirtualGL-Users] extension
Another user ran into this same issue and attempted all of my proposed fixes below. None worked. At this point I'm stymied. I'm going to try bringing up a simple C# OpenGL demo in mono, but if I can't get that to fail in the same way, I don't know what else can be done without the app. On 4/15/11 5:17 AM, DRC wrote: David, We seem to have stalled out on this, and there were a lot of rapid-fire e-mails exchanged between you and Nathan, in which multiple things were tried and multiple interleaved results posted, so this e-mail is my attempt to summarize what we know. I would encourage everyone involved to attempt to consolidate their responses into one e-mail and wait for a reply before posting another one. -- The problem is clearly due to librrfaker.so not being loaded properly into the app. Thus, when the app attempts to call a GLX command, it fails because TurboVNC has no GLX extension. -- After examining the VirtualGL trace output from the app, it does appear that VirtualGL is being successfully loaded into something. GLX functions are being called, at least initially. However, with complex apps, one never knows whether librrfaker.so is being loaded successfully into one process but not successfully into another. -- Referencing your attempt to run with vglrun -d :1.0, don't do that. It's incorrect. -d specifies the 3D X server, which should almost always be left at the default of :0.0. -- Referencing your attempt to run with -c proxy, that is implied in TurboVNC, so no need to specify it. -- This type of problem is an issue between librrfaker.so and the app, so it will not matter whether you are running in TurboVNC or using the VGL Transport and an SSH connection. -- A possible explanation for the ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. message is that either the application or something else launched from the application's script is a setuid/setgid executable (refer to Chapter 12 of the VirtualGL User's Guide.) On modern Linux systems, this error will not prevent an executable from launching, so if the error were being generated by an executable in the script (other than the main application), then it should be innocuous, but if the main application is generating the error, then that would explain why librrfaker.so is not being loaded. Since you have tried moving vglrun down to the bottom of the launch script (which I gather is a line that starts mono), then that eliminates the possibility that something launched by the script is causing the problem. However, mono might be setuid/setgid, or some other executable it launches might be. -- We know your VirtualGL setup works, because you were able to vglrun glxgears. -- The indirect context messages are very odd. For starters, when you specified vglrun -d 1.0, VirtualGL never should have made it as far as printing that message, because TurboVNC does not have a GLX extension. The only scenario I can come up with is that somehow VirtualGL is loading the version of libGL.so.1 that is shipped with the application. -- The 'Xlib: extension NV-GLX missing on display localhost:10.0.' message is innocuous and always occurs when running any type of 3D application remotely with nVidia drivers on the server end. Blame nVidia. So, let's be scientific about this and try a few different configurations that should help me narrow down what is going on. For each of these, post the console output (not tracing information, just the simple output from VirtualGL and the application as you try to launch it.) (A) -- Set the setuid bit on librrfaker.so and libdlfaker.so. As root, chmod u+s /usr/lib/librrfaker.so chmod u+s /usr/lib/libdlfaker.so chmod u+s /usr/lib64/librrfaker.so chmod u+s /usr/lib64/libdlfaker.so -- Use an unmodified application environment and application startup script -- Use TurboVNC as the 2D X server -- vglrun the application startup script with no arguments to vglrun If (A) doesn't work, then I need you to run the following configurations. You've run some of these before, but I need to see the console output from each for comparison (for instance, attached as consoleA.log, consoleB.log, etc.): (B) -- Leave the setuid bits set on librrfaker.so and libdlfaker.so -- Modify the startup script so that vglrun prefixes the last command (presumably 'mono'.) -- Execute the modified startup script (without using vglrun) in TurboVNC (C) -- Unset the setuid bits on librrfaker.so and libdlfaker.so (replace chmod u+s with chmod u-s in the above) -- Leave the startup script modified -- Execute the modified startup script (without using vglrun) in TurboVNC (D) -- Leave the setuid bits on librrfaker.so and libdlfaker.so unset -- Leave the startup script modified -- Rename any instances of libGL.so* in the application's install directory to something else. -- Execute the modified
Re: [VirtualGL-Users] extension
David, We seem to have stalled out on this, and there were a lot of rapid-fire e-mails exchanged between you and Nathan, in which multiple things were tried and multiple interleaved results posted, so this e-mail is my attempt to summarize what we know. I would encourage everyone involved to attempt to consolidate their responses into one e-mail and wait for a reply before posting another one. -- The problem is clearly due to librrfaker.so not being loaded properly into the app. Thus, when the app attempts to call a GLX command, it fails because TurboVNC has no GLX extension. -- After examining the VirtualGL trace output from the app, it does appear that VirtualGL is being successfully loaded into something. GLX functions are being called, at least initially. However, with complex apps, one never knows whether librrfaker.so is being loaded successfully into one process but not successfully into another. -- Referencing your attempt to run with vglrun -d :1.0, don't do that. It's incorrect. -d specifies the 3D X server, which should almost always be left at the default of :0.0. -- Referencing your attempt to run with -c proxy, that is implied in TurboVNC, so no need to specify it. -- This type of problem is an issue between librrfaker.so and the app, so it will not matter whether you are running in TurboVNC or using the VGL Transport and an SSH connection. -- A possible explanation for the ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. message is that either the application or something else launched from the application's script is a setuid/setgid executable (refer to Chapter 12 of the VirtualGL User's Guide.) On modern Linux systems, this error will not prevent an executable from launching, so if the error were being generated by an executable in the script (other than the main application), then it should be innocuous, but if the main application is generating the error, then that would explain why librrfaker.so is not being loaded. Since you have tried moving vglrun down to the bottom of the launch script (which I gather is a line that starts mono), then that eliminates the possibility that something launched by the script is causing the problem. However, mono might be setuid/setgid, or some other executable it launches might be. -- We know your VirtualGL setup works, because you were able to vglrun glxgears. -- The indirect context messages are very odd. For starters, when you specified vglrun -d 1.0, VirtualGL never should have made it as far as printing that message, because TurboVNC does not have a GLX extension. The only scenario I can come up with is that somehow VirtualGL is loading the version of libGL.so.1 that is shipped with the application. -- The 'Xlib: extension NV-GLX missing on display localhost:10.0.' message is innocuous and always occurs when running any type of 3D application remotely with nVidia drivers on the server end. Blame nVidia. So, let's be scientific about this and try a few different configurations that should help me narrow down what is going on. For each of these, post the console output (not tracing information, just the simple output from VirtualGL and the application as you try to launch it.) (A) -- Set the setuid bit on librrfaker.so and libdlfaker.so. As root, chmod u+s /usr/lib/librrfaker.so chmod u+s /usr/lib/libdlfaker.so chmod u+s /usr/lib64/librrfaker.so chmod u+s /usr/lib64/libdlfaker.so -- Use an unmodified application environment and application startup script -- Use TurboVNC as the 2D X server -- vglrun the application startup script with no arguments to vglrun If (A) doesn't work, then I need you to run the following configurations. You've run some of these before, but I need to see the console output from each for comparison (for instance, attached as consoleA.log, consoleB.log, etc.): (B) -- Leave the setuid bits set on librrfaker.so and libdlfaker.so -- Modify the startup script so that vglrun prefixes the last command (presumably 'mono'.) -- Execute the modified startup script (without using vglrun) in TurboVNC (C) -- Unset the setuid bits on librrfaker.so and libdlfaker.so (replace chmod u+s with chmod u-s in the above) -- Leave the startup script modified -- Execute the modified startup script (without using vglrun) in TurboVNC (D) -- Leave the setuid bits on librrfaker.so and libdlfaker.so unset -- Leave the startup script modified -- Rename any instances of libGL.so* in the application's install directory to something else. -- Execute the modified startup script (without using vglrun) in TurboVNC (E) -- Leave the setuid bits on librrfaker.so and libdlfaker.so unset -- Revert the startup script to its unmodified state -- Leave the libGL.so* files renamed -- vglrun the unmodified startup script in TurboVNC without any arguments to vglrun. On 3/23/11 9:23 AM, Nathan Kidd wrote: On 11-03-23 09:48 AM, r...@englobe-tec.com wrote: When using launcher130 I get the
Re: [VirtualGL-Users] extension
Hi, Thanks for your help. I will try those solutions after vacations. Kind regards David El 15/04/2011 12:17, DRC escribió: David, We seem to have stalled out on this, and there were a lot of rapid-fire e-mails exchanged between you and Nathan, in which multiple things were tried and multiple interleaved results posted, so this e-mail is my attempt to summarize what we know. I would encourage everyone involved to attempt to consolidate their responses into one e-mail and wait for a reply before posting another one. -- The problem is clearly due to librrfaker.so not being loaded properly into the app. Thus, when the app attempts to call a GLX command, it fails because TurboVNC has no GLX extension. -- After examining the VirtualGL trace output from the app, it does appear that VirtualGL is being successfully loaded into something. GLX functions are being called, at least initially. However, with complex apps, one never knows whether librrfaker.so is being loaded successfully into one process but not successfully into another. -- Referencing your attempt to run with vglrun -d :1.0, don't do that. It's incorrect. -d specifies the 3D X server, which should almost always be left at the default of :0.0. -- Referencing your attempt to run with -c proxy, that is implied in TurboVNC, so no need to specify it. -- This type of problem is an issue between librrfaker.so and the app, so it will not matter whether you are running in TurboVNC or using the VGL Transport and an SSH connection. -- A possible explanation for the ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. message is that either the application or something else launched from the application's script is a setuid/setgid executable (refer to Chapter 12 of the VirtualGL User's Guide.) On modern Linux systems, this error will not prevent an executable from launching, so if the error were being generated by an executable in the script (other than the main application), then it should be innocuous, but if the main application is generating the error, then that would explain why librrfaker.so is not being loaded. Since you have tried moving vglrun down to the bottom of the launch script (which I gather is a line that starts mono), then that eliminates the possibility that something launched by the script is causing the problem. However, mono might be setuid/setgid, or some other executable it launches might be. -- We know your VirtualGL setup works, because you were able to vglrun glxgears. -- The indirect context messages are very odd. For starters, when you specified vglrun -d 1.0, VirtualGL never should have made it as far as printing that message, because TurboVNC does not have a GLX extension. The only scenario I can come up with is that somehow VirtualGL is loading the version of libGL.so.1 that is shipped with the application. -- The 'Xlib: extension NV-GLX missing on display localhost:10.0.' message is innocuous and always occurs when running any type of 3D application remotely with nVidia drivers on the server end. Blame nVidia. So, let's be scientific about this and try a few different configurations that should help me narrow down what is going on. For each of these, post the console output (not tracing information, just the simple output from VirtualGL and the application as you try to launch it.) (A) -- Set the setuid bit on librrfaker.so and libdlfaker.so. As root, chmod u+s /usr/lib/librrfaker.so chmod u+s /usr/lib/libdlfaker.so chmod u+s /usr/lib64/librrfaker.so chmod u+s /usr/lib64/libdlfaker.so -- Use an unmodified application environment and application startup script -- Use TurboVNC as the 2D X server -- vglrun the application startup script with no arguments to vglrun If (A) doesn't work, then I need you to run the following configurations. You've run some of these before, but I need to see the console output from each for comparison (for instance, attached as consoleA.log, consoleB.log, etc.): (B) -- Leave the setuid bits set on librrfaker.so and libdlfaker.so -- Modify the startup script so that vglrun prefixes the last command (presumably 'mono'.) -- Execute the modified startup script (without using vglrun) in TurboVNC (C) -- Unset the setuid bits on librrfaker.so and libdlfaker.so (replace chmod u+s with chmod u-s in the above) -- Leave the startup script modified -- Execute the modified startup script (without using vglrun) in TurboVNC (D) -- Leave the setuid bits on librrfaker.so and libdlfaker.so unset -- Leave the startup script modified -- Rename any instances of libGL.so* in the application's install directory to something else. -- Execute the modified startup script (without using vglrun) in TurboVNC (E) -- Leave the setuid bits on librrfaker.so and libdlfaker.so unset -- Revert the startup script to its unmodified state -- Leave the libGL.so* files renamed
Re: [VirtualGL-Users] extension
On 11-03-29 04:52 PM, DRC wrote: NOTE: that error can also be displayed when attempting to use VirtualGL with an executable that is setuid root, but I can't imagine that that would be the case with ANSYS. It could be, however, that one of the executables that the launcher130 script invokes is setuid root. I don't know if there's anything else I can do remotely. I really need to play with the application first-hand to see what it's doing. I got a chance to run ANSYS 13.0 on a remote system using VirtualGL 2.1.4 running on the Exceed onDemand 8 proxy with the GLX extension disabled. Some random notes but not a complete investigation: 1. Workbench (runwb2) launches fine, trace shows VGL successfully hooking glX functions 2. If you launch CFD-Post from Workbench you get the following error and a blank workspace (no GLX window) The application has encountered an unexpected problem: QGLContext::makeCurrent(): Cannot make invalid context current. Please report this error, along with the circumstances in which it occurred. Alternatively, you may attempt to continue, but the application may be in an unstable state, and you should save your work and restart the application as soon as possible. The following information may be useful to CFX support: src/QtWarningHandler.cxx(49) : Expectation failed: QGLContext::makeCurrent(): Cannot make invalid context current. Animator4 and ANSYS both use the QT wrapper for OpenGL and show this same error. Google helpfully provides: http://cep.xor.aps.anl.gov/software/qt4-x11-4.2.2-browser/de/db4/class_q_g_l_context.html#6919d9abb1136d8e791f44bb840ada14 So the source of the error is the app calls ::makeCurrent(), which decides the current QGLContext has invalid GLX context (.valid == false) I noticed QT had some tracing functionality which might give enough of a clue to build a stand-alone QT OpenGL app that is possible to debug. Definitely more investigation warranted. 3. if you launch CFD-Post independently then it works fine 4. the fact that runwb2 itself uses LD_PRELOAD to force Mesa off-screen rendering if it doesn't detect local direct rendering suggests that the problem isn't LD_PRELOAD. Maybe the issue is LD_LIBRARY_PATH getting killed in the exec launch. Need to check that. (runwb2 puts fully-qualified paths in LD_PRELOAD) Let me know of any ideas of further things to check when I get time. -Nathan On 3/23/11 9:23 AM, Nathan Kidd wrote: On 11-03-23 09:48 AM, r...@englobe-tec.com wrote: When using launcher130 I get the following error, does it give any light on the issue? ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. It means the system couldn't find librrfaker.so or couldn't find a version with the correct bit-ness (32/64). This is a situation where your LD_DEBUG=libs log will show you exactly which paths it tried to load librrfaker.so, so you can see where the problem is. -Nathan -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
Re: [VirtualGL-Users] extension
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px;
}Hello!
I tried with the same result.
I've also tried accessing through ssh X forwarding, also with the
same result.
Thanks
David
On Mon 8:31 PM , DRC dcomman...@users.sourceforge.net sent:
Did you try renaming the version of libGL.so.1 that is installed by
the
application?
On 3/21/11 11:45 AM, wrote:
I've tried this and there are new lines in the output.
[VGL] WARNING: The OpenGL rendering context obtained on X display
[VGL]:0.0 is indirect, which may cause performance to suffer.
[VGL]If :0.0 is a local X display, then the framebuffer device
[VGL]permissions may be set incorrectly.
[VGL] WARNING: The OpenGL rendering context obtained on X display
[VGL]:0.0 is indirect, which may cause performance to suffer.
[VGL]If :0.0 is a local X display, then the framebuffer device
[VGL]permissions may be set incorrectly.
And then the usual:
Xlib: extension GLX missing on display :1.0.
I've tried with -nodl and -c proxy with the same results.
Thanks
David
On Mon 5:15 PM , Nathan Kidd sent:
BTW, if you can't make sense from ld.log another simple way is
to put
the vglrun command inside the runwb2 script (prefix the mono
command).
That will narrow down if mono is unhappy or it is the script.
-Nathan
On 11-03-17 12:28 PM,
wrote:
Hi Nathan,
I wish a good healing for you. Thanks for your time and
efforts.
I sent the log in another mail but it seems like it was
blocked
somewhere
I'll go further with this since I really want to use my 3D
accelerator
remotely. Perhaps someone else in the list has seen anything
similar.
The first mention to librrfaker.so was the following:
22848: find library=librrfaker.so [0]; searching
22848: search path=/opt/gridengine/lib/lx26-amd64
(LD_LIBRARY_PATH)
22848: trying
file=/opt/gridengine/lib/lx26-amd64/librrfaker.so
22848: search cache=/etc/ld.so.cache
22848: trying file=/usr/lib64/librrfaker.so
And /usrlib64/librrfaker.so exists.
The only matches for error are like the following:
22848: /usr/lib64/gconv/ISO8859-15.so: error: symbol lookup
error:
undefined symbol: gconv_end (fatal)
23134:
/ansys_inc/v130/Framework/bin/Linux64/libComponentSystem.so:
error: symbol lookup error: undefined symbol: CoInitialize
(fatal)
23134:
/ansys_inc/v130/Framework/bin/Linux64/libLocalization.Base.so:
error: symbol lookup error: undefined symbol:
GetTranslationW (fatal)
Thanks!
On Thu 4:50 PM , Nathan Kidd
sent:
On 11-03-17 07:55 AM,
wrote:
LD_PRELOAD=librrfaker.so ls returned the usual ls output
(no error
messages there). So I atach ld.log files to this mail.
Using LD_DEBUG_OUTPUT to something like ld.log kept
returning that
grep
output in the console, even unsetting +tr or setting
VGL_LOG. I set
LD_DEBUG_OUTPUT to an absolute path into my home dir and
it
worked. But
output was split in many files. I send you them compressed
in one
tar.gz.
I also atach a compressed vgl.log.
I don't see anything attached.
However, my health has been going up and down for a while
and seems to
be going down again right now, so I won't likely look at
that log for a
good while. Sorry.
What *you* can look for is which process is execing, and
does it try to
load librrfaker, and if so does it succeed; if not what
paths did it
try.
-Nathan
On Wed 9:23 PM , Nathan Kidd
sent:
On 37-01--10 02:59 PM,
wrote:
I've tried the suggestions you gave:
1.- Adding -oglhw gave no apparent result
2.- Adding those 2 lines to the script added the
following lines
to the
output:
libdlfaker.so:librrfaker.so
/ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64
So VirtualGL's lib path isn't there, but I'm reminded that
vglrun
works
a little differently than how I usually launch VirtualGL;
it expects
librrfaker.so to be in the lib path. A simple way to
ensure
they're in
the
Re: [VirtualGL-Users] extension
When using launcher130 I get the following error, does it give any light on the issue? ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
Re: [VirtualGL-Users] extension
I've added -d :1.0 to the vglrun in the script and the output changed to: [VGL] WARNING: The OpenGL rendering context obtained on X display [VGL]:1.0 is indirect, which may cause performance to suffer. [VGL]If :1.0 is a local X display, then the framebuffer device [VGL]permissions may be set incorrectly. [VGL] WARNING: The OpenGL rendering context obtained on X display [VGL]:1.0 is indirect, which may cause performance to suffer. [VGL]If :1.0 is a local X display, then the framebuffer device [VGL]permissions may be set incorrectly. Followed again by many: Xlib: extension GLX missing on display :1.0. Thanks David On Mon 5:45 PM , r...@englobe-tec.com sent: I've tried this and there are new lines in the output. [VGL] WARNING: The OpenGL rendering context obtained on X display [VGL]:0.0 is indirect, which may cause performance to suffer. [VGL]If :0.0 is a local X display, then the framebuffer device [VGL]permissions may be set incorrectly. [VGL] WARNING: The OpenGL rendering context obtained on X display [VGL]:0.0 is indirect, which may cause performance to suffer. [VGL]If :0.0 is a local X display, then the framebuffer device [VGL]permissions may be set incorrectly. And then the usual: Xlib: extension GLX missing on display :1.0. I've tried with -nodl and -c proxy with the same results. Thanks David On Mon 5:15 PM , Nathan Kidd nathan...@spicycrypto.ca sent: BTW, if you can't make sense from ld.log another simple way is to put the vglrun command inside the runwb2 script (prefix the mono command). That will narrow down if mono is unhappy or it is the script. -Nathan On 11-03-17 12:28 PM, wrote: Hi Nathan, I wish a good healing for you. Thanks for your time and efforts. I sent the log in another mail but it seems like it was blocked somewhere I'll go further with this since I really want to use my 3D accelerator remotely. Perhaps someone else in the list has seen anything similar. The first mention to librrfaker.so was the following: 22848: find library=librrfaker.so [0]; searching 22848: search path=/opt/gridengine/lib/lx26-amd64 (LD_LIBRARY_PATH) 22848: trying file=/opt/gridengine/lib/lx26-amd64/librrfaker.so 22848: search cache=/etc/ld.so.cache 22848: trying file=/usr/lib64/librrfaker.so And /usrlib64/librrfaker.so exists. The only matches for error are like the following: 22848: /usr/lib64/gconv/ISO8859-15.so: error: symbol lookup error: undefined symbol: gconv_end (fatal) 23134: /ansys_inc/v130/Framework/bin/Linux64/libComponentSystem.so: error: symbol lookup error: undefined symbol: CoInitialize (fatal) 23134: /ansys_inc/v130/Framework/bin/Linux64/libLocalization.Base.so: error: symbol lookup error: undefined symbol: GetTranslationW (fatal) Thanks! On Thu 4:50 PM , Nathan Kidd sent: On 11-03-17 07:55 AM, wrote: LD_PRELOAD=librrfaker.so ls returned the usual ls output (no error messages there). So I atach ld.log files to this mail. Using LD_DEBUG_OUTPUT to something like ld.log kept returning that grep output in the console, even unsetting +tr or setting VGL_LOG. I set LD_DEBUG_OUTPUT to an absolute path into my home dir and it worked. But output was split in many files. I send you them compressed in one tar.gz. I also atach a compressed vgl.log. I don't see anything attached. However, my health has been going up and down for a while and seems to be going down again right now, so I won't likely look at that log for a good while. Sorry. What *you* can look for is which process is execing, and does it try to load librrfaker, and if so does it succeed; if not what paths did it try. -Nathan On Wed 9:23 PM , Nathan Kidd sent: On 37-01--10 02:59 PM, wrote: I've tried the suggestions you gave: 1.- Adding -oglhw gave no apparent result 2.- Adding those 2 lines to the script added the following lines to the output: libdlfaker.so:librrfaker.so /ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64 So VirtualGL's lib path isn't there, but I'm reminded that vglrun works a little differently than how I usually launch VirtualGL; it expects librrfaker.so to be in the lib path. A simple way
Re: [VirtualGL-Users] extension
Did you try renaming the version of libGL.so.1 that is installed by the
application?
On 3/21/11 11:45 AM, r...@englobe-tec.com wrote:
I've tried this and there are new lines in the output.
[VGL] WARNING: The OpenGL rendering context obtained on X display
[VGL]:0.0 is indirect, which may cause performance to suffer.
[VGL]If :0.0 is a local X display, then the framebuffer device
[VGL]permissions may be set incorrectly.
[VGL] WARNING: The OpenGL rendering context obtained on X display
[VGL]:0.0 is indirect, which may cause performance to suffer.
[VGL]If :0.0 is a local X display, then the framebuffer device
[VGL]permissions may be set incorrectly.
And then the usual:
Xlib: extension GLX missing on display :1.0.
I've tried with -nodl and -c proxy with the same results.
Thanks
David
On Mon 5:15 PM , Nathan Kidd nathan...@spicycrypto.ca sent:
BTW, if you can't make sense from ld.log another simple way is to put
the vglrun command inside the runwb2 script (prefix the mono command).
That will narrow down if mono is unhappy or it is the script.
-Nathan
On 11-03-17 12:28 PM, r...@englobe-tec.com
javascript:top.opencompose('r...@englobe-tec.com','','','') wrote:
Hi Nathan,
I wish a good healing for you. Thanks for your time and efforts.
I sent the log in another mail but it seems like it was blocked
somewhere
I'll go further with this since I really want to use my 3D accelerator
remotely. Perhaps someone else in the list has seen anything similar.
The first mention to librrfaker.so was the following:
22848: find library=librrfaker.so [0]; searching
22848: search path=/opt/gridengine/lib/lx26-amd64 (LD_LIBRARY_PATH)
22848: trying file=/opt/gridengine/lib/lx26-amd64/librrfaker.so
22848: search cache=/etc/ld.so.cache
22848: trying file=/usr/lib64/librrfaker.so
And /usrlib64/librrfaker.so exists.
The only matches for error are like the following:
22848: /usr/lib64/gconv/ISO8859-15.so: error: symbol lookup error:
undefined symbol: gconv_end (fatal)
23134: /ansys_inc/v130/Framework/bin/Linux64/libComponentSystem.so:
error: symbol lookup error: undefined symbol: CoInitialize (fatal)
23134: /ansys_inc/v130/Framework/bin/Linux64/libLocalization.Base.so:
error: symbol lookup error: undefined symbol: GetTranslationW (fatal)
Thanks!
On Thu 4:50 PM , Nathan Kidd nathan...@spicycrypto.ca
javascript:top.opencompose('nathan...@spicycrypto.ca','','','') sent:
On 11-03-17 07:55 AM, r...@englobe-tec.com
javascript:top.opencompose('r...@englobe-tec.com','','','') wrote:
LD_PRELOAD=librrfaker.so ls returned the usual ls output (no error
messages there). So I atach ld.log files to this mail.
Using LD_DEBUG_OUTPUT to something like ld.log kept returning that
grep
output in the console, even unsetting +tr or setting VGL_LOG. I set
LD_DEBUG_OUTPUT to an absolute path into my home dir and it
worked. But
output was split in many files. I send you them compressed in one
tar.gz.
I also atach a compressed vgl.log.
I don't see anything attached.
However, my health has been going up and down for a while and seems to
be going down again right now, so I won't likely look at that log for a
good while. Sorry.
What *you* can look for is which process is execing, and does it try to
load librrfaker, and if so does it succeed; if not what paths did it
try.
-Nathan
On Wed 9:23 PM , Nathan Kidd nathan...@spicycrypto.ca
javascript:top.opencompose('nathan...@spicycrypto.ca','','','') sent:
On 37-01--10 02:59 PM, r...@englobe-tec.com
javascript:top.opencompose('r...@englobe-tec.com','','','')
wrote:
I've tried the suggestions you gave:
1.- Adding -oglhw gave no apparent result
2.- Adding those 2 lines to the script added the following lines
to the
output:
libdlfaker.so:librrfaker.so
/ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64
So VirtualGL's lib path isn't there, but I'm reminded that vglrun
works
a little differently than how I usually launch VirtualGL; it expects
librrfaker.so
Re: [VirtualGL-Users] extension
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }Hi
Nathan,
LD_PRELOAD=librrfaker.so ls returned the usual ls output (no error
messages there). So I atach ld.log files to this mail.
Using LD_DEBUG_OUTPUT to something like ld.log kept returning that
grep output in the console, even unsetting +tr or setting VGL_LOG. I
set LD_DEBUG_OUTPUT to an absolute path into my home dir and it
worked. But output was split in many files. I send you them
compressed in one tar.gz.
I also atach a compressed vgl.log.
Thanks for all.
David
On Wed 9:23 PM , Nathan Kidd nathan...@spicycrypto.ca sent:
On 37-01--10 02:59 PM, wrote:
I've tried the suggestions you gave:
1.- Adding -oglhw gave no apparent result
2.- Adding those 2 lines to the script added the following lines
to the
output:
libdlfaker.so:librrfaker.so
/ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64
So VirtualGL's lib path isn't there, but I'm reminded that vglrun
works
a little differently than how I usually launch VirtualGL; it expects
librrfaker.so to be in the lib path. A simple way to ensure they're
in
the lib path is to run:
LD_PRELOAD=librrfaker.so ls
If the command fails to run (can't find librrfaker.so) then the
issue is
with library path setup on your box. If it works then we'll
probably
need to see the ld.log output.
3.- Setting the environment vars:
export LD_DEBUG_OUTPUT=ld.log
export LD_DEBUG=libs
Resulted in the application not being launched and the output is
like
the following:
$ /opt/VirtualGL/bin/vglrun
/ansys_inc/v130/Framework/bin/Linux64/runwb2
-oglhw
grep: find: No such file or directory
grep: library=libdlfaker.so: No such file or directory
I think you also ran with vglrun with +tr right? The script died
because
VGL's trace logs were captured in some of the scripts commands.
When using the +tr command with a script you pretty-well *must*
specify
VGL_LOG=vgl.log to prevent the trace output from confusing any
commands
in the script that are capturing output (since all the scripts
commands
get the faker loaded too).
If you run again with VGL_LOG and the LD_DEBUG variables set then
perhaps vgl.log and ld.log will tell us something useful.
Please zip the logs to avoid any problem with the mailing list
blocking
things too large.
-Nathan
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
Re: [VirtualGL-Users] extension
On 11-03-17 07:55 AM, r...@englobe-tec.com wrote:
LD_PRELOAD=librrfaker.so ls returned the usual ls output (no error
messages there). So I atach ld.log files to this mail.
Using LD_DEBUG_OUTPUT to something like ld.log kept returning that grep
output in the console, even unsetting +tr or setting VGL_LOG. I set
LD_DEBUG_OUTPUT to an absolute path into my home dir and it worked. But
output was split in many files. I send you them compressed in one tar.gz.
I also atach a compressed vgl.log.
I don't see anything attached.
However, my health has been going up and down for a while and seems to
be going down again right now, so I won't likely look at that log for a
good while. Sorry.
What *you* can look for is which process is execing, and does it try to
load librrfaker, and if so does it succeed; if not what paths did it try.
-Nathan
On Wed 9:23 PM , Nathan Kidd nathan...@spicycrypto.ca sent:
On 37-01--10 02:59 PM, r...@englobe-tec.com
javascript:top.opencompose('r...@englobe-tec.com','','','') wrote:
I've tried the suggestions you gave:
1.- Adding -oglhw gave no apparent result
2.- Adding those 2 lines to the script added the following lines
to the
output:
libdlfaker.so:librrfaker.so
/ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64
So VirtualGL's lib path isn't there, but I'm reminded that vglrun works
a little differently than how I usually launch VirtualGL; it expects
librrfaker.so to be in the lib path. A simple way to ensure they're in
the lib path is to run:
LD_PRELOAD=librrfaker.so ls
If the command fails to run (can't find librrfaker.so) then the
issue is
with library path setup on your box. If it works then we'll probably
need to see the ld.log output.
3.- Setting the environment vars:
export LD_DEBUG_OUTPUT=ld.log
export LD_DEBUG=libs
Resulted in the application not being launched and the output is like
the following:
$ /opt/VirtualGL/bin/vglrun
/ansys_inc/v130/Framework/bin/Linux64/runwb2
-oglhw
grep: find: No such file or directory
grep: library=libdlfaker.so: No such file or directory
I think you also ran with vglrun with +tr right? The script died
because
VGL's trace logs were captured in some of the scripts commands.
When using the +tr command with a script you pretty-well *must* specify
VGL_LOG=vgl.log to prevent the trace output from confusing any commands
in the script that are capturing output (since all the scripts commands
get the faker loaded too).
If you run again with VGL_LOG and the LD_DEBUG variables set then
perhaps vgl.log and ld.log will tell us something useful.
Please zip the logs to avoid any problem with the mailing list blocking
things too large.
-Nathan
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
Re: [VirtualGL-Users] extension
body { font-family: Arial,Helvetica,sans-serif; font-size: 12px; }Hi
Nathan,
I wish a good healing for you. Thanks for your time and efforts.
I sent the log in another mail but it seems like it was blocked
somewhere
I'll go further with this since I really want to use my 3D
accelerator remotely. Perhaps someone else in the list has seen
anything similar.
The first mention to librrfaker.so was the following:
22848: find library=librrfaker.so [0]; searching
22848: search path=/opt/gridengine/lib/lx26-amd64
(LD_LIBRARY_PATH)
22848: trying
file=/opt/gridengine/lib/lx26-amd64/librrfaker.so
22848: search cache=/etc/ld.so.cache
22848: trying file=/usr/lib64/librrfaker.so
And /usrlib64/librrfaker.so exists.
The only matches for error are like the following:
22848: /usr/lib64/gconv/ISO8859-15.so: error: symbol lookup
error: undefined symbol: gconv_end (fatal)
23134:
/ansys_inc/v130/Framework/bin/Linux64/libComponentSystem.so: error:
symbol lookup error: undefined symbol: CoInitialize (fatal)
23134:
/ansys_inc/v130/Framework/bin/Linux64/libLocalization.Base.so: error:
symbol lookup error: undefined symbol: GetTranslationW (fatal)
Thanks!
On Thu 4:50 PM , Nathan Kidd nathan...@spicycrypto.ca sent:
On 11-03-17 07:55 AM, r...@englobe-tec.com wrote:
LD_PRELOAD=librrfaker.so ls returned the usual ls output (no
error
messages there). So I atach ld.log files to this mail.
Using LD_DEBUG_OUTPUT to something like ld.log kept returning that
grep
output in the console, even unsetting +tr or setting VGL_LOG. I
set
LD_DEBUG_OUTPUT to an absolute path into my home dir and it
worked. But
output was split in many files. I send you them compressed in one
tar.gz.
I also atach a compressed vgl.log.
I don't see anything attached.
However, my health has been going up and down for a while and seems
to
be going down again right now, so I won't likely look at that log
for a
good while. Sorry.
What *you* can look for is which process is execing, and does it try
to
load librrfaker, and if so does it succeed; if not what paths did it
try.
-Nathan
On Wed 9:23 PM , Nathan Kidd nathan...@spicycrypto.ca sent:
On 37-01--10 02:59 PM, r...@englobe-tec.com
wrote:
I've tried the suggestions you gave:
1.- Adding -oglhw gave no apparent result
2.- Adding those 2 lines to the script added the following
lines
to the
output:
libdlfaker.so:librrfaker.so
/ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64
So VirtualGL's lib path isn't there, but I'm reminded that
vglrun works
a little differently than how I usually launch VirtualGL; it
expects
librrfaker.so to be in the lib path. A simple way to ensure
they're in
the lib path is to run:
LD_PRELOAD=librrfaker.so ls
If the command fails to run (can't find librrfaker.so) then
the
issue is
with library path setup on your box. If it works then we'll
probably
need to see the ld.log output.
3.- Setting the environment vars:
export LD_DEBUG_OUTPUT=ld.log
export LD_DEBUG=libs
Resulted in the application not being launched and the
output is like
the following:
$ /opt/VirtualGL/bin/vglrun
/ansys_inc/v130/Framework/bin/Linux64/runwb2
-oglhw
grep: find: No such file or directory
grep: library=libdlfaker.so: No such file or directory
I think you also ran with vglrun with +tr right? The script
died
because
VGL's trace logs were captured in some of the scripts
commands.
When using the +tr command with a script you pretty-well
*must* specify
VGL_LOG=vgl.log to prevent the trace output from confusing any
commands
in the script that are capturing output (since all the scripts
commands
get the faker loaded too).
If you run again with VGL_LOG and the LD_DEBUG variables set
then
perhaps vgl.log and ld.log will tell us something useful.
Please zip the logs to avoid any problem with the mailing list
blocking
things too large.
-Nathan
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
Re: [VirtualGL-Users] extension
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px;
}I've checked that vglgears runs well with vglrun through TurboVNC.
This confirms that the problem is reduced to the concrete application.
On Thu 4:50 PM , Nathan Kidd nathan...@spicycrypto.ca sent:
On 11-03-17 07:55 AM, wrote:
LD_PRELOAD=librrfaker.so ls returned the usual ls output (no
error
messages there). So I atach ld.log files to this mail.
Using LD_DEBUG_OUTPUT to something like ld.log kept returning that
grep
output in the console, even unsetting +tr or setting VGL_LOG. I
set
LD_DEBUG_OUTPUT to an absolute path into my home dir and it
worked. But
output was split in many files. I send you them compressed in one
tar.gz.
I also atach a compressed vgl.log.
I don't see anything attached.
However, my health has been going up and down for a while and seems
to
be going down again right now, so I won't likely look at that log
for a
good while. Sorry.
What *you* can look for is which process is execing, and does it try
to
load librrfaker, and if so does it succeed; if not what paths did it
try.
-Nathan
On Wed 9:23 PM , Nathan Kidd sent:
On 37-01--10 02:59 PM,
wrote:
I've tried the suggestions you gave:
1.- Adding -oglhw gave no apparent result
2.- Adding those 2 lines to the script added the following
lines
to the
output:
libdlfaker.so:librrfaker.so
/ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64
So VirtualGL's lib path isn't there, but I'm reminded that
vglrun works
a little differently than how I usually launch VirtualGL; it
expects
librrfaker.so to be in the lib path. A simple way to ensure
they're in
the lib path is to run:
LD_PRELOAD=librrfaker.so ls
If the command fails to run (can't find librrfaker.so) then
the
issue is
with library path setup on your box. If it works then we'll
probably
need to see the ld.log output.
3.- Setting the environment vars:
export LD_DEBUG_OUTPUT=ld.log
export LD_DEBUG=libs
Resulted in the application not being launched and the
output is like
the following:
$ /opt/VirtualGL/bin/vglrun
/ansys_inc/v130/Framework/bin/Linux64/runwb2
-oglhw
grep: find: No such file or directory
grep: library=libdlfaker.so: No such file or directory
I think you also ran with vglrun with +tr right? The script
died
because
VGL's trace logs were captured in some of the scripts
commands.
When using the +tr command with a script you pretty-well
*must* specify
VGL_LOG=vgl.log to prevent the trace output from confusing any
commands
in the script that are capturing output (since all the scripts
commands
get the faker loaded too).
If you run again with VGL_LOG and the LD_DEBUG variables set
then
perhaps vgl.log and ld.log will tell us something useful.
Please zip the logs to avoid any problem with the mailing list
blocking
things too large.
-Nathan
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
Re: [VirtualGL-Users] extension
Yes, that is quite possible. http://sourceforge.net/mailarchive/forum.php?thread_name=201009161641.14204.nate%40hpcintegrators.comforum_name=virtualgl-users and http://sourceforge.net/tracker/?func=detailaid=3005112group_id=117509atid=678327 may shed some insight. Some things to try (in the order listed): (1) Running with vglrun -nodl (2) Adding import os os.environ['ABAQUS_EMULATE_OVERLAYS'] = 1 to the abaqus_v6.env file. (3) Renaming Abaqus' version of libGL.so.1 to something else. On 3/17/11 12:01 PM, r...@englobe-tec.com wrote: Seems like my previous messages didn't reach the list (perhaps due to the attachments) I reproduce here the last one. Regarding to this... could be that the libGL.so.1 used by ANSYS (installed into its directory) has a diferent version or is conflicting with the one provided by the system? * Hi Nathan, I wish a good healing for you. Thanks for your time and efforts. I sent the log in another mail but it seems like it was blocked somewhere I'll go further with this since I really want to use my 3D accelerator remotely. Perhaps someone else in the list has seen anything similar. The first mention to librrfaker.so was the following: 22848: find library=librrfaker.so [0]; searching 22848: search path=/opt/gridengine/lib/lx26-amd64 (LD_LIBRARY_PATH) 22848: trying file=/opt/gridengine/lib/lx26-amd64/librrfaker.so 22848: search cache=/etc/ld.so.cache 22848: trying file=/usr/lib64/librrfaker.so And /usrlib64/librrfaker.so exists. The only matches for error are like the following: 22848: /usr/lib64/gconv/ISO8859-15.so: error: symbol lookup error: undefined symbol: gconv_end (fatal) 23134: /ansys_inc/v130/Framework/bin/Linux64/libComponentSystem.so: error: symbol lookup error: undefined symbol: CoInitialize (fatal) 23134: /ansys_inc/v130/Framework/bin/Linux64/libLocalization.Base.so: error: symbol lookup error: undefined symbol: GetTranslationW (fatal) Thanks! On Thu 5:54 PM , r...@englobe-tec.com sent: I've checked that vglgears runs well with vglrun through TurboVNC. This confirms that the problem is reduced to the concrete application. On Thu 4:50 PM , Nathan Kidd nathan...@spicycrypto.ca sent: On 11-03-17 07:55 AM, r...@englobe-tec.com javascript:top.opencompose( wrote: LD_PRELOAD=librrfaker.so ls returned the usual ls output (no error messages there). So I atach ld.log files to this mail. Using LD_DEBUG_OUTPUT to something like ld.log kept returning that grep output in the console, even unsetting +tr or setting VGL_LOG. I set LD_DEBUG_OUTPUT to an absolute path into my home dir and it worked. But output was split in many files. I send you them compressed in one tar.gz. I also atach a compressed vgl.log. I don't see anything attached. However, my health has been going up and down for a while and seems to be going down again right now, so I won't likely look at that log for a good while. Sorry. What *you* can look for is which process is execing, and does it try to load librrfaker, and if so does it succeed; if not what paths did it try. -Nathan On Wed 9:23 PM , Nathan Kidd nathan...@spicycrypto.ca javascript:top.opencompose( sent: On 37-01--10 02:59 PM, r...@englobe-tec.com javascript:top.opencompose( wrote: I've tried the suggestions you gave: 1.- Adding -oglhw gave no apparent result 2.- Adding those 2 lines to the script added the following lines to the output: libdlfaker.so:librrfaker.so /ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64 So VirtualGL's lib path isn't there, but I'm reminded that vglrun works a little differently than how I usually launch VirtualGL; it expects librrfaker.so to be in the lib path. A simple way to ensure they're in the lib path is to run: LD_PRELOAD=librrfaker.so ls If the command fails to run (can't find librrfaker.so) then the issue is with library path
Re: [VirtualGL-Users] extension
On 37-01--10 02:59 PM, r...@englobe-tec.com wrote: I've tried the suggestions you gave: 1.- Adding -oglhw gave no apparent result 2.- Adding those 2 lines to the script added the following lines to the output: libdlfaker.so:librrfaker.so /ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64 So VirtualGL's lib path isn't there, but I'm reminded that vglrun works a little differently than how I usually launch VirtualGL; it expects librrfaker.so to be in the lib path. A simple way to ensure they're in the lib path is to run: LD_PRELOAD=librrfaker.so ls If the command fails to run (can't find librrfaker.so) then the issue is with library path setup on your box. If it works then we'll probably need to see the ld.log output. 3.- Setting the environment vars: export LD_DEBUG_OUTPUT=ld.log export LD_DEBUG=libs Resulted in the application not being launched and the output is like the following: $ /opt/VirtualGL/bin/vglrun /ansys_inc/v130/Framework/bin/Linux64/runwb2 -oglhw grep: find: No such file or directory grep: library=libdlfaker.so: No such file or directory I think you also ran with vglrun with +tr right? The script died because VGL's trace logs were captured in some of the scripts commands. When using the +tr command with a script you pretty-well *must* specify VGL_LOG=vgl.log to prevent the trace output from confusing any commands in the script that are capturing output (since all the scripts commands get the faker loaded too). If you run again with VGL_LOG and the LD_DEBUG variables set then perhaps vgl.log and ld.log will tell us something useful. Please zip the logs to avoid any problem with the mailing list blocking things too large. -Nathan -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
Re: [VirtualGL-Users] extension GLX missing on display :1.0
You're missing vglrun. Please read the docs. On 3/15/11 11:55 AM, r...@englobe-tec.com wrote: Hi all, I'm having problems to use VirtualGL in a server. I have a NVIDIA Quadro FX 4800. When running ANSYS 13.0 workbench from TurboVNC I get this message in the output: extension GLX missing on display :1.0 And the graphic parts of the interface appear blank (also, shadowed parts look somewhat crappy). If I run glxinfo for my remote desktop (display :1) I get the following: $ /opt/VirtualGL/bin/glxinfo name of display: :1.0 Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. Error: couldn't find RGB GLX visual visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. But the local console seems to be OK and 3D acceleration is running. Tell me if I'm wrong (output pasted at the end of this post). Am I missing anything? sure I am, but what? :) Thanks! $ /opt/VirtualGL/bin/glxinfo -display :0 -c name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image, GLX_NV_video_capture client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_copy_image, GLX_NV_multisample_coverage, GLX_NV_video_capture, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image, GLX_NV_video_capture, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro 5000/PCI/SSE2 OpenGL version string: 4.1.0 NVIDIA 260.19.44 OpenGL extensions: GL_ARB_blend_func_extended, GL_ARB_color_buffer_float, GL_ARB_compatibility, GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, GL_ARB_draw_indirect, GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, GL_ARB_ES2_compatibility, GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_framebuffer_sRGB, GL_ARB_geometry_shader4, GL_ARB_get_program_binary, GL_ARB_gpu_shader5, GL_ARB_gpu_shader_fp64, GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, GL_ARB_imaging, GL_ARB_instanced_arrays, GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_occlusion_query2, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sample_shading, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map, GL_ARB_separate_shader_objects, GL_ARB_shader_bit_encoding, GL_ARB_shader_objects, GL_ARB_shader_precision, GL_ARB_shader_subroutine, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_sync, GL_ARB_tessellation_shader, GL_ARB_texture_border_clamp, GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_object_rgb32, GL_ARB_texture_compression, GL_ARB_texture_compression_bptc, GL_ARB_texture_compression_rgtc,
Re: [VirtualGL-Users] extension
The root of the problem is that VirtualGL is not being engaged for some reason, so the application is trying to send GLX commands directly to TurboVNC (which fails, because TurboVNC doesn't have the GLX extension, as you saw below when you tried to run glxinfo without vglrun.) Adding +v +tr to the vglrun arguments will produce voluminous tracing output that might shed some light on what is going on. Please capture both that output and the output from the application (it probably writes to a log, so the output of VirtualGL might go to that same log) and upload them here. With any application-specific issue like this, if I can't immediately discern what is happening by reading the trace output, the only other recourse is to get a copy of the app to debug. Nathan, any chance you have this app and could test it? On 3/15/11 1:11 PM, r...@englobe-tec.com wrote: I'm sorry I didn't mention that I run ANSYS with this command: /opt/VirtualGL/bin/vglrun /ansys_inc/v130/Framework/bin/Linux64/runwb2 I've also tried with -c proxy option. I've re-read the whole documentation and repeated all the install and config process just in case. I've also searched in the mail archives for similar issues (there are some of them, but the solution didn't apply in this case. Any suggestions about where can I find more debug info on this? Thanks! On Tue 7:01 PM , DRC dcomman...@users.sourceforge.net sent: You're missing vglrun. Please read the docs. On 3/15/11 11:55 AM, r...@englobe-tec.com mailto:r...@englobe-tec.com wrote: Hi all, I'm having problems to use VirtualGL in a server. I have a NVIDIA Quadro FX 4800. When running ANSYS 13.0 workbench from TurboVNC I get this message in the output: extension GLX missing on display :1.0 And the graphic parts of the interface appear blank (also, shadowed parts look somewhat crappy). If I run glxinfo for my remote desktop (display :1) I get the following: $ /opt/VirtualGL/bin/glxinfo name of display: :1.0 Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. Error: couldn't find RGB GLX visual visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. But the local console seems to be OK and 3D acceleration is running. Tell me if I'm wrong (output pasted at the end of this post). Am I missing anything? sure I am, but what? :) Thanks! $ /opt/VirtualGL/bin/glxinfo -display :0 -c name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image, GLX_NV_video_capture client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_copy_image, GLX_NV_multisample_coverage, GLX_NV_video_capture, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image, GLX_NV_video_capture,
Re: [VirtualGL-Users] extension
On 11-03-15 02:43 PM, DRC wrote: The root of the problem is that VirtualGL is not being engaged for some reason, With any application-specific issue like this, if I can't immediately discern what is happening by reading the trace output, the only other recourse is to get a copy of the app to debug. Nathan, any chance you have this app and could test it? I have access to eval of v1.2.1 in which runwb2 seems to preserve LD_LIBRARY_PATH properly, but will clobber LD_PRELOAD if it is set to use MESA mode (software-based off screen rendering). I suggest: 1) try running runwb2 with the -oglhw option (forces to not set LD_PRELOAD) 2) Just before mono is executed at the end of that script try putting: echo $LD_PRELOAD echo $LD_LIBRARY_PATH 3) before running vglrun try: export LD_DEBUG_OUTPUT=ld.log export LD_DEBUG=libs ld.log will be long, but show which processes actually loaded librrfaker.so. -Nathan On 3/15/11 1:11 PM, r...@englobe-tec.com wrote: I'm sorry I didn't mention that I run ANSYS with this command: /opt/VirtualGL/bin/vglrun /ansys_inc/v130/Framework/bin/Linux64/runwb2 I've also tried with -c proxy option. I've re-read the whole documentation and repeated all the install and config process just in case. I've also searched in the mail archives for similar issues (there are some of them, but the solution didn't apply in this case. Any suggestions about where can I find more debug info on this? Thanks! On Tue 7:01 PM , DRC dcomman...@users.sourceforge.net sent: You're missing vglrun. Please read the docs. On 3/15/11 11:55 AM, r...@englobe-tec.com mailto:r...@englobe-tec.com wrote: Hi all, I'm having problems to use VirtualGL in a server. I have a NVIDIA Quadro FX 4800. When running ANSYS 13.0 workbench from TurboVNC I get this message in the output: extension GLX missing on display :1.0 And the graphic parts of the interface appear blank (also, shadowed parts look somewhat crappy). If I run glxinfo for my remote desktop (display :1) I get the following: $ /opt/VirtualGL/bin/glxinfo name of display: :1.0 Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. Error: couldn't find RGB GLX visual visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- Xlib: extension GLX missing on display :1.0. Xlib: extension GLX missing on display :1.0. But the local console seems to be OK and 3D acceleration is running. Tell me if I'm wrong (output pasted at the end of this post). Am I missing anything? sure I am, but what? :) Thanks! $ /opt/VirtualGL/bin/glxinfo -display :0 -c name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image, GLX_NV_video_capture client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_copy_image, GLX_NV_multisample_coverage, GLX_NV_video_capture, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile,
Re: [VirtualGL-Users] extension GLX missing on display
OK, so perhaps I should have said it doesn't have full 3D acceleration, but the result is the same. Most built-in Linux drivers are 2.5D accelerated at best. Let me put this another way-- the 3D driver must support Pbuffer-enabled FB configs in order to work in a VirtualGL server. NVIDIA and ATI boards using the respective drivers from those vendors are the only configurations that are known to support Pbuffer-enabled FB configs. Thus, these boards are the only ones known to work in a VirtualGL server. If you discover another configuration that works, let us know about it, and I'll be glad to update the docs to reflect this. Most likely, Mesa is reporting that GLX_SGIX_pbuffer is available, but it isn't actually implemented in the underlying driver. I've seen that before. Jose Rodriguez wrote: 2009/11/21 DRC dcomman...@users.sourceforge.net: This adapter is not using 3D acceleration. Note that the OpenGL renderer is Mesa. That's software OpenGL. You need hardware-accelerated OpenGL, which is only going to come from an NVidia or ATI adapter with the vendor's 3D drivers installed. I have to disagree with you about this. The lines: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM GEM 20090712 2009Q2 RC3 x86/MMX/SSE2 OpenGL version string: 1.3 Mesa 7.6 indicate that a) the OpenGL implementation the 3D driver is using is Mesa, by Tungsten Graphics; b) that it is being hardware accelerated (DRI=direct rendering infrastructure). If this was not the case, that line would read: OpenGL renderer string: Software Rasterizer I think there may be a bit of confusion about this. I noticed that the VirtualGL documentation says Install the vendor drivers for the server’s 3D graphics card. Do not use the drivers that ship with Linux, as these do not provide 3D acceleration or Pbuffer support. But I thought the reason was that the docs weren't up to date. Actually, the OSS drivers provide 3D acceleration for ATI cards from R100 to R500 and there's already experimental support for more recent generations. Also, Intel cards have had 3D linux support since long ago. Regarding pixel buffers, I can't be so sure--especially with this very low end card of mine. However, the extension GLX_SGIX_pbuffer is present, and the Xorg developer who took a look at my glxinfo mentioned a couple of other extensions related to it (which I can't remember). Is there anything I can do to get to the bottom of this? I still don't discard the possibility that I haven't set up the whole thing properly, or that some oddness somewhere is causing problems with permissions or what have you. Also, I'll soon have another laptop of mine back with and ATI card, I could try with that one with both the proprietary and the open source driver. Regards Jose -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
Re: [VirtualGL-Users] extension GLX missing on display
Not having accelerated 3D drivers installed is the most obvious cause of that VirtualGL error message. Just because GLX exists doesn't mean that Pbuffers are available. In general, you have to install the vendor drivers for the 3D graphics card in order to get Pbuffers. The output of '/opt/VirtualGL/bin/glxinfo -display :0 -c' will tell you whether or not any Pbuffer visuals exist (look for a 'P' in the last column on any of the visuals.) Jose Rodriguez wrote: I'm trying to get this working but I don't see where the problem is. I didn't have any *dm so I installed one to be sure that there is a 'real' X server running. Then I started vncserver from /opt/TurboVNC/bin: ps aux | grep X root 2251 0.2 2.8 13012 7144 tty7 Ss+ 19:33 0:03 /usr/bin/X11/X -nolisten tcp -auth /var/run/slim.auth vt07 jose 2667 0.1 3.2 12288 8036 pts/1S 19:45 0:01 ./Xvnc :1 -desktop X -httpd ./../vnc/classes -auth /home/jose/.Xauthority -dontdisconnect -geometry 400x300 -depth 24 -rfbwait 12 -rfbauth /home/jose/.vnc/passwd -rfbport 5901 -fp /usr/share/fonts/X11//misc,/usr/share/fonts/X11//75dpi,/usr/share/fonts/X11//100dpi,/usr/share/fonts/X11//Type1 -co /usr/share/X11/rgb -deferupdate 1 xdpyinfo -display :0 name of display::0.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:10605000 X.Org version: 1.6.5 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 0xa00025, revert to None number of extensions:26 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SGI-GLX 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:1024x768 pixels (270x203 millimeters) resolution:96x96 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0xfd depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0x30801d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask ExposureMask SubstructureRedirectMask FocusChangeMask number of visuals:72 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits [...] xdpyinfo -display :1 name of display::1.0 version number:11.0 vendor string:ATT Laboratories Cambridge vendor release number:3332 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x112, revert to Parent number of extensions:7 BIG-REQUESTS MIT-SHM MIT-SUNDRY-NONSTANDARD SHAPE SYNC XC-MISC XTEST default screen number:0 number of screens:1 screen #0: dimensions:400x300 pixels (135x102 millimeters) resolution:75x75 dots per inch depths (1):24 root window id:0x25 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x21 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store YES, save-unders YES largest cursor:400x300 current input event mask:0x30801d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask ExposureMask SubstructureRedirectMask FocusChangeMask number of visuals:1 default visual id: 0x22 visual: visual
