[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | open3d |
| Notice: | Kits on notes 3 and 4; Documents note 223 |
| Moderator: | WRKSYS::COULTER |
|
| Created: | Wed Dec 09 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1306 |
| Total number of notes: | 5260 |
1302.0. "HOOPS failing to initialize OpenGL driver" by OSLLAV::JENSH (Jens Holwech, SBU Workstation Sales Support, Norway (DTN 872-8543)) Thu May 29 1997 17:49
We're trying to set up a demo of a third party application
doing computational fluid dynamics: Fine from NUMECA.
The application uses HOOPS for graphics, with the choice of
an OpenGL or X11 driver. The application was linked under
UNIX V3.2(something), and we're trying to run it under
V4.0C with Open3D V4.3 on a PWS433au with PowerStorm 4D50T.
The X11 driver sort of works, but makes the application
horribly slow, i.e. practically unusable.
HOOPS displays this error message when attempting to
initialize the OpenGL driver:
"HOOPS error handler (2,2)
There was an unexpected Hoops internal error -
create_window() cannot find visual for OpenGL.
While calling
Enable_Selection_Events"
I've attached the output from xdpyinfo, which indicates
that the default visual is 24 bit TrueColor.
The behavior is identical for DECwindows Motif & CDE. We
have also tried disabling double buffering in HOOPS,
aswell as disabling use of the stream extension (ref.
note 1262.*)
Is this as expected, or might there be a way to make this
application function without recompiling/relinking?
Regards,
Jens
Output from xdpyinfo:
name of display: :0.0
version number: 11.0
vendor string: DECWINDOWS Digital Equipment Corporation Digital UNIX V4.0
vendor release number: 1
maximum request size: 4194300 bytes
motion buffer size: 100
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 6
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 12, bits_per_pixel 32, 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 0x3000038, revert to PointerRoot
number of extensions: 26
Adobe-DPS-Extension
BIG-REQUESTS
DEC-Direct-Render
DEC-E3-SPECIAL
DEC-GLX
DEC-PEER-GLX
DEC-XTRAP
DECStereo
DOUBLE-BUFFER
DPMS
DPSExtension
GLX
Keyboard-Management-Extension
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
Multi-Buffering
SHAPE
SYNC
Shared-Memory Transport
XC-MISC
XIE
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1280x1024 pixels (346x277 millimeters)
resolution: 94x94 dots per inch
depths (7): 1, 4, 8, 12, 24, 32, 4
root window id: 0x38
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 10
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: 0x30203c
ButtonPressMask ButtonReleaseMask EnterWindowMask
LeaveWindowMask ButtonMotionMask SubstructureRedirectMask
FocusChangeMask
number of visuals: 22
default visual id: 0x22
visual:
visual id: 0x2c
class: DirectColor
depth: 8 planes
available colormap entries: 8 per subfield
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
visual:
visual id: 0x2d
class: TrueColor
depth: 8 planes
available colormap entries: 8 per subfield
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
visual:
visual id: 0x2e
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x2f
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x30
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x31
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x33
class: StaticColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
visual:
visual id: 0x34
class: GrayScale
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x35
class: StaticGray
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x36
class: StaticGray
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x21
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x22
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x23
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x24
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x25
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x27
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x29
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x2a
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x2b
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x32
class: PseudoColor
depth: 4 planes
available colormap entries: 16
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 4 bits
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1302.1 | | WRKSYS::COULTER | If this typewriter can't do it, ... | Fri May 30 1997 08:59 | 17 |
| > We're trying to set up a demo of a third party application
> doing computational fluid dynamics: Fine from NUMECA.
> The application uses HOOPS for graphics, with the choice of
> an OpenGL or X11 driver. The application was linked under
> UNIX V3.2(something), and we're trying to run it under
> V4.0C with Open3D V4.3 on a PWS433au with PowerStorm 4D50T.
>
> The X11 driver sort of works, but makes the application
> horribly slow, i.e. practically unusable.
If the link you did under "UNIX V3.2(something)" is a STATIC
link, i.e., doesn't allow for new shareable (.so) images, then
you have no chance of working. The PowerStorm 4D50T requires
new X11 and OpenGL libraries to work on the PWS433au (aka "MX5").
Re-link is a minimum, or you live with "X11 driver sort of works".
|
| 1302.2 | How to test for static vs dynamic linking | VESPER::VESPER | OpenGL Alpha Geek | Fri May 30 1997 09:57 | 28 |
| > If the link you did under "UNIX V3.2(something)" is a STATIC
> link, i.e., doesn't allow for new shareable (.so) images, then
> you have no chance of working. The PowerStorm 4D50T requires
> new X11 and OpenGL libraries to work on the PWS433au (aka "MX5").
If you don't know how the application/hoops library was linked, you
can either use the 'odump' command with the -D switch and look for
a line:
NEEDED: libGL.so
However, if the hoops library is a .so that was itself linked statically,
this might not be sufficient and you will need to use odump on the hoops
library.
Another method is to:
setenv _RLD_FLAGS -v
and watch to see what libraries are being loaded.
You should also run 'xglinfo' instead of/in addition to xdpyinfo. xglinfo
reports what the OpenGL characteristics of the visuals are.
Finally, what is the DISPLAY string set to? For best results this should
be ":0" or perhaps "local:0".
Andy V
|
| 1302.3 | possibly related problem, but probably not | HYDRA::DONSBACH | Jeff Donsbach, Software Partner Engineering, DTN 297-6862 | Fri May 30 1997 16:35 | 15 |
|
Not sure if this is a related problem, but here is a problem I found a
few days ago with Pro/E. I supposed I should PTT it:
The Open3D license on a particular system had expired, but the GLX
extension is still loaded by the XServer and advertised by the X Server
as being available. Pro/E, seeing GLX was available at startup, tried
to initialize itself to use the OpenGL driver. But, before long, the
X Server crashes and you end up back at a CDE Login screen.
The fix was to load an unexpired Open 3D license. You could also work
around the problem by forcing Pro/E to run in X Windows mode.
-Jeff D.
|
| 1302.4 | | WRKSYS::COULTER | If this typewriter can't do it, ... | Sat May 31 1997 00:42 | 4 |
|
Open3D licenses expire??
|
| 1302.5 | Being worked by application vendor | OSLLAV::JENSH | Jens Holwech, SBU Workstation Sales Support, Norway (DTN 872-8543) | Mon Jun 02 1997 06:27 | 100 |
| This issue is now actively being worked by NUMECA.
Thanks for the odump tips! The image appears to be
dynamically linked:
# odump -D fine
***DYNAMIC SECTION***
Tag Value
fine:
UNREFEXTNO: 14.
LOCAL_GOTNO: 1488.
GOTSYM: 2184.
LOCAL_GOTNO: 5078.
GOTSYM: 5773.
CONFLICT: 0x0000000120047610
CONFLICTNO: 345.
RLD_VERSION: 2.
HASH: 0x000000012009dc50
STRTAB: 0x0000000120047b80
SYMTAB: 0x0000000120076ad0
STRSZ: 192324.
SYMENT: 24.
PLTGOT: 0x0000000140079920
SYMTABNO: 6672.
BASE_ADDRESS: 0x0000000120000000
HIPAGENO: 0.
RELSZ: 106560.
RELENT: 16.
REL: 0x0000000120000980
RPATH: /usr/lib/cmplrs/cxx
LIBLISTNO: 13.
LIBLIST: 0x0000000120000870
NEEDED: librwtool.so.2
NEEDED: librwmth.so
NEEDED: libXext.so
NEEDED: libX11.so
NEEDED: libXm.so
NEEDED: libcomplex.so
NEEDED: libm.so
NEEDED: libhoops.so
NEEDED: libPEX5.so
NEEDED: libGL.so
NEEDED: libGLU.so
NEEDED: libcxx.so
NEEDED: libc.so
INIT: 0x00000001203a7090
FINI: 0x00000001203a7e70
FLAGS: 0x00000000
There are no dependencies in the libhoops.so library, though:
# odump -D ./_lib_s/libhoops.so
***DYNAMIC SECTION***
Tag Value
./_lib_s/libhoops.so:
UNREFEXTNO: 14.
LOCAL_GOTNO: 2098.
GOTSYM: 1124.
LOCAL_GOTNO: 4128.
GOTSYM: 3153.
SONAME: libhoops.so
TIME_STAMP: (0x30fa0d93) Mon Jan 15 09:17:23 1996
ICHECKSUM: 0x3e007775
CONFLICTNO: 0.
RLD_VERSION: 2.
HASH: 0x000003ffbfc70260
STRTAB: 0x000003ffbfc4cd00
SYMTAB: 0x000003ffbfc5d600
STRSZ: 67825.
SYMENT: 24.
PLTGOT: 0x000003fffffed860
SYMTABNO: 3204.
BASE_ADDRESS: 0x000003ffbfc40000
HIPAGENO: 0.
RELSZ: 50656.
RELENT: 16.
REL: 0x000003ffbfc40720
LIBLISTNO: 0.
INIT: 0x000003ffbfff7e50
FINI: 0x000003ffbfff7e90
FLAGS: 0x00000001
We already tried playing around with the DISPLAY setting, but without
any improvement.
We had an active Open3D license on this system, and other OpenGL
applications worked just fine.
I expect it'll be easier for the people with the source code (i.e.
NUMECA in Belgium) to sort this out... ;-)
Regards,
Jens
|
| 1302.6 | | WRKSYS::CHALTAS | Power of the Platypus! | Mon Jun 02 1997 09:29 | 9 |
| Re .3
Already PTT-ed.
Re .4
ISV's in some support programs are supplied free-of-charge with
licenses for DIGITAL software products that are good for a limited
period of time, generally less than 1 year.
|