I compiled SDL-1.2.0 on an Ultra 60 Solaris 2.6 machine.
I got everything compiled and installed.
When I try to run the test programs, some failed, namely those requiring
video output.
I get the following error:
./testgamma
Couldn’t initialize SDL: No available video device
I have an Elite 3D card with the machine. I am running the CDE desktop.
What gives?
Salman
I get the following error:
./testgamma
Couldn’t initialize SDL: No available video device
I have an Elite 3D card with the machine. I am running the CDE desktop.
with that hardware there shouldn’t be any problem (but please send me
the output of xdpyinfo just in case).
Compile with debugging (which should be the default), set a breakpoint in
SDL_VideoInit(), X11_Available(), and X11_CreateDevice() and see what
happens when you step through those functions. Tell me if you need more help
Mattias Engdeg?rd wrote:
I get the following error:
./testgamma
Couldn’t initialize SDL: No available video device
I have an Elite 3D card with the machine. I am running the CDE desktop.
with that hardware there shouldn’t be any problem (but please send me
the output of xdpyinfo just in case).Compile with debugging (which should be the default), set a breakpoint in
SDL_VideoInit(), X11_Available(), and X11_CreateDevice() and see what
happens when you step through those functions. Tell me if you need more help
Here is my output from xdpyinfo. I don’t know how to to what you said in the
paragraph about compiling with breakpoint, etc.
name of display: :0.0
version number: 11.0
vendor string: Sun Microsystems, Inc.
vendor release number: 3600
maximum request size: 262140 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, MSBFirst, 32
image byte order: MSBFirst
number of supported pixmap formats: 3
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 132
focus: window 0x440002d, revert to PointerRoot
number of extensions: 21
AccessX
Adobe-DPS-Extension
DOUBLE-BUFFER
DPSExtension
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
Multi-Buffering
SHAPE
SUN_ALLPLANES
SUN_DGA
SUN_OVL
SUN_SME
SYNC
SolarisIA
X3D-PEX
XC-MISC
XIE
XInputDeviceEvents
XInputExtension
XTEST
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1280x1024 pixels (361x288 millimeters)
resolution: 90x90 dots per inch
depths (3): 1, 8, 24
root window id: 0x37
depth of root window: 8 planes
number of colormaps: minimum 1, maximum 5
default colormap: 0x34
default number of colormap cells: 256
preallocated pixels: black 1, white 0
options: backing-store YES, save-unders YES
largest cursor: 64x64
current input event mask: 0x78003f
KeyPressMask KeyReleaseMask ButtonPressMask
ButtonReleaseMask EnterWindowMask LeaveWindowMask
SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask
PropertyChangeMask
number of visuals: 16
default visual id: 0x20
visual:
visual id: 0x20
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: 0x21
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: 0x22
class: StaticColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x23
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: 0x24
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: 0x25
class: TrueColor
depth: 8 planes
available colormap entries: 8 per subfield
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: DirectColor
depth: 8 planes
available colormap entries: 8 per subfield
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x27
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: 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: 255
red, green, blue masks: 0x0, 0x0, 0x0
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: 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: 0x2b
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: 0x2c
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: 0x2d
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
Here is my output from xdpyinfo. I don’t know how to to what you said in the
paragraph about compiling with breakpoint, etc.
The xdpyinfo output looks exactly as expected. Make sure that the X11
driver was properly built (look at the output from the configure script).
Easiest is probably if you find an IRC client and join the #sdl channel at
irc.openprojects.net; there you will find people who can hand-hold you
to find the problem.
Otherwise, try the following: make sure you have gdb installed.
Go the the sdl test directory and say
gdb testsprite
and then, when gdb has started,
b main
run
gdb will then stop at the beginning of your program. Now say
b X11_Available
b X11_CreateDevice
Assuming gdb accepts these commands, say “continue”. Hopefully gdb will
stop inside the library in either of these functions. Then type “finish”,
possibly several times, until the program exits. Please mail me a
transcript of the entire gdb session.
Mattias Engdeg?rd wrote:
Here is my output from xdpyinfo. I don’t know how to to what you said in the
paragraph about compiling with breakpoint, etc.The xdpyinfo output looks exactly as expected. Make sure that the X11
driver was properly built (look at the output from the configure script).Easiest is probably if you find an IRC client and join the #sdl channel at
irc.openprojects.net; there you will find people who can hand-hold you
to find the problem.Otherwise, try the following: make sure you have gdb installed.
Go the the sdl test directory and saygdb testsprite
and then, when gdb has started,
b main
rungdb will then stop at the beginning of your program. Now say
b X11_Available
b X11_CreateDeviceAssuming gdb accepts these commands, say “continue”. Hopefully gdb will
stop inside the library in either of these functions. Then type “finish”,
possibly several times, until the program exits. Please mail me a
transcript of the entire gdb session.
magoo(/folks/salman/SDL-1.2.0/test)176: gdb testsprite
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for
details.
This GDB was configured as “sparc-sun-solaris2.6”…
Breakpoint 1 at 0x114f4: file testsprite.c, line 140.
(gdb) quit
magoo(/folks/salman/SDL-1.2.0/test)177: gdb testgamma
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for
details.
This GDB was configured as “sparc-sun-solaris2.6”…
Breakpoint 1 at 0x1109c: file testgamma.c, line 79.
(gdb) b main
Note: breakpoint 1 also set at pc 0x1109c.
Breakpoint 2 at 0x1109c: file testgamma.c, line 79.
(gdb) run
Starting program: /folks/salman/SDL-1.2.0/test/testgamma
[New LWP 1]
[New LWP 2]
[New LWP 3]
Breakpoint 1, main (argc=1, argv=0xefffea84) at testgamma.c:79
79 argv += get_video_args(argv, &w, &h, &bpp, &flags);
(gdb) b X11_Available
Function “X11_Available” not defined.
(gdb) b X11_CreateDevice
Function “X11_CreateDevice” not defined.
(gdb) continue
Continuing.
Couldn’t initialize SDL: No available video device
Program exited with code 01.
(gdb) finish
The program is not running.
(gdb) quit
(gdb) b X11_Available
Function “X11_Available” not defined.
(gdb) b X11_CreateDevice
Function “X11_CreateDevice” not defined.
seems that you don’t have the X11 driver compiled in. Look closely at
what the configure script says. Try
nm libSDL.so | grep X11_Available
(where you have libSDL.so installed). It should tell you if it’s there
Also make sure that you can run other X11 applications from the
same window (like xterm)
Another tip is to set the environment variable SDL_DEBUG to "1"
and watch for otherwise hidden error messages.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
It is something broken with configure on solaris,
configure sometimes fails to include X11 or any other video-driver.
I could never figure it out, and I thought it was my fault or our
system…
I think it happens when you run configure twice, I once solved it by
handediting the generated configure-files 
Since we are talking about solaris I have some other problems as well:
testsprite and testpalette gives me black and white sprites and backgrounds
but testalpha works ok with colors.
This happend at the same time as I installed sdl-1.2 and solaris
X/opengl-patches packages, so it migth not sdl’s fault.
I got a big memory leak, it seems that something is not closed
correctly or unmapped as it should, when I have created an opengl
window, my process adress space grows with 200Meg,
when I close the window I call SDL_quit(), the
adress space doesn’t shrink, so if start a new window in the same process
it grows with another 200M. This could also be a solaris issue aswell…
/Dan
PS: My SDL-Erlang port can be found at
http://www.ericsson.se/cslab/~dgud/esdl/
Sam Lantinga writes:
Also make sure that you can run other X11 applications from the
same window (like xterm)Another tip is to set the environment variable SDL_DEBUG to "1"
and watch for otherwise hidden error messages.See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
/Dan
It is something broken with configure on solaris,
configure sometimes fails to include X11 or any other video-driver.
check the config.log when this happens, and tell us why. post the log if
you can’t figure it out
testsprite and testpalette gives me black and white sprites and backgrounds
but testalpha works ok with colors.
This happend at the same time as I installed sdl-1.2 and solaris
X/opengl-patches packages, so it migth not sdl’s fault.
I got a big memory leak, it seems that something is not closed
correctly or unmapped as it should, when I have created an opengl
window, my process adress space grows with 200Meg,
when I close the window I call SDL_quit(), the
adress space doesn’t shrink, so if start a new window in the same process
it grows with another 200M. This could also be a solaris issue aswell…
is that 200M of allocated memory or just a mapped framebuffer?
use qps or pmap to find out
Mattias Engdeg?rd writes:
It is something broken with configure on solaris,
configure sometimes fails to include X11 or any other video-driver.check the config.log when this happens, and tell us why. post the log if
you can’t figure it out
I’ll send it next time it happens, it worked great in the latest install
testsprite and testpalette gives me black and white sprites and backgrounds
but testalpha works ok with colors.
This happend at the same time as I installed sdl-1.2 and solaris
X/opengl-patches packages, so it migth not sdl’s fault.
Any comments??
is that 200M of allocated memory or just a mapped framebuffer?
use qps or pmap to find out
/usr/proc/bin/pmap 27520
27520: /net/strider/ldisk/daily_build/otp_beam_solaris7_p8a.2001-04-17_19/otp
00010000 656K read/exec /net/strider/ldisk/daily_build/otp_beam_solaris7_p8a.2001-04-17_19/otp/erts-5.1/bin/beam
000C2000 120K read/write/exec /net/strider/ldisk/daily_build/otp_beam_solaris7_p8a.2001-04-17_19/otp/erts-5.1/bin/beam
000E0000 2912K read/write/exec [ heap ]
F0400000 192616K read/write
FC400000 15784K read/exec /usr/openwin/platform/sun4u/lib/GL/oglSUNWsrz.so.6
FD378000 104K read/write/exec /usr/openwin/platform/sun4u/lib/GL/oglSUNWsrz.so.6
FD600000 760K read/exec /usr/openwin/lib/GL/devhandlers/oglSUNWffb.so.6
FD6CC000 16K read/write/exec /usr/openwin/lib/GL/devhandlers/oglSUNWffb.so.6
FD700000 96K read/exec /usr/openwin/platform/sun4u/lib/GL/libcompgeom.so.1
FD726000 16K read/write/exec /usr/openwin/platform/sun4u/lib/GL/libcompgeom.so.1
…
F0400000 192616K read/write
it’s probably this one. qps can give you device/inode, but I bet it’s
/dev/fb0