How can I tell SDL to default to svgalib?

SDL Development
1

i have completely follow the steps in faq

make distclean;
./configure --enable-video-svga ;
make install
then i run ./testwin
I get the error: "no video devices available"
i have check the env viarable ,and SDL_VIDEODRIVER =
“svga”.
why this happen .
i have install the svgalib at /usr/local/lib
why the test demo cannot find it ?

but if i install the sdl in the default mode , i.e ,no
parameter is specified. I can run the test demo on
X-window.__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

2

I get the error: "no video devices available"
i have check the env viarable ,and SDL_VIDEODRIVER = “svga”.
why this happen .
i have install the svgalib at /usr/local/lib
why the test demo cannot find it ?

For svgalib, export SDL_VIDEODRIVER=svgalib

I think you need to run the program as root for it to be able to use
svgalib, too, although there may just be some devices you can set the
permissions on…?On Thu, 24 Jan 2002, tony Tong wrote:

–
Mike.

3

Correct, any application which runs under svgalib must be SUID or run as
root. SVGALib is kind enough to drop permissions immediately, but that
doesn’t mean it’s a safe thing. This is one reason that SVGALib is all
but completely deprecated at this point in favor of the framebuffer
device. Of course, the integration between this and X is almost nil, so
while it works, it may not work 100% with X, and of course there’s almost
no chance of having OpenGL on the framebuffer. (Too bad, that’d rock!)On Fri, Jan 25, 2002 at 04:37:34PM +0800, Mike wrote:

For svgalib, export SDL_VIDEODRIVER=svgalib

I think you need to run the program as root for it to be able to use
svgalib, too, although there may just be some devices you can set the
permissions on…?

–
Joseph Carter Don’t feed the sigs

2.3.1 has been released. Folks new to this game should remember that
2.3.* releases are development kernels, with no guarantees that they
will not cause your system to do horrible things like corrupt its
disks, catch fire, or start running Mindcraft benchmarks.
– Slashdot

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020125/546969c3/attachment.pgp

4
  • Joseph Carter on Fri, Jan 25, 2002:> On Fri, Jan 25, 2002 at 04:37:34PM +0800, Mike wrote:

For svgalib, export SDL_VIDEODRIVER=svgalib

I think you need to run the program as root for it to be able to use
svgalib, too, although there may just be some devices you can set the
permissions on…?

device. Of course, the integration between this and X is almost nil, so
while it works, it may not work 100% with X, and of course there’s almost
no chance of having OpenGL on the framebuffer. (Too bad, that’d rock!)

I suggest you read up on what’s happening with the DRI project before
spouting truisms.

DRM and the framebuffer will learn to share in Linux 2.5, and 2D/3D driver
seperation from X dependence will ensure that the DRI will be available for
multiple platforms and varying environments.

Of course, OpenGL runs on the framebuffer currently anyway…

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020125/a894da39/attachment.pgp

5

device. Of course, the integration between this and X is almost nil, so
while it works, it may not work 100% with X, and of course there’s almost
no chance of having OpenGL on the framebuffer. (Too bad, that’d rock!)

I suggest you read up on what’s happening with the DRI project before
spouting truisms.

Don’t bother to repeat promises and vaporware announcements. RIGHT NOW,
they are not guaranteed to work together well. The only reason it works
at all is because of a series of kludges which amount to a house of cards
waiting to be toppled. That may change in the next year or two, but
that’s a year or two away. Today, it can’t be expected to work.

DRM and the framebuffer will learn to share in Linux 2.5, and 2D/3D driver
seperation from X dependence will ensure that the DRI will be available for
multiple platforms and varying environments.

Fine, when and if all of that happens, Linux will be a lot better off.
But right now I don’t see any of that.

Of course, OpenGL runs on the framebuffer currently anyway…

If “runs” is the word you’d use for an unaccellerated implementation which
all but pukes on itself the first time you try basic blending operations,
then sure it does. Yet SDL does not support this configuration. I can
only assume this is because nobody else actually believes it would be at
all worthwhile to support it. I personally can’t disagree since I tend to
measure OpenGL performance in frames per second as opposed to seconds per
frame.On Fri, Jan 25, 2002 at 04:18:12PM -0600, M. R. Brown wrote:

–
Joseph Carter Not many fishes

  • Knghtbrd unleashes a pair of double barreled snurf guns and covers
    jesus with snurf darts
    meany :stuck_out_tongue:

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020125/464c116a/attachment.pgp

6
  • Joseph Carter on Fri, Jan 25, 2002:

device. Of course, the integration between this and X is almost nil, so
while it works, it may not work 100% with X, and of course there’s almost
no chance of having OpenGL on the framebuffer. (Too bad, that’d rock!)

I suggest you read up on what’s happening with the DRI project before
spouting truisms.

Don’t bother to repeat promises and vaporware announcements. RIGHT NOW,
they are not guaranteed to work together well. The only reason it works
at all is because of a series of kludges which amount to a house of cards
waiting to be toppled. That may change in the next year or two, but
that’s a year or two away. Today, it can’t be expected to work.

[…]

Fine, when and if all of that happens, Linux will be a lot better off.
But right now I don’t see any of that.

[…]

If “runs” is the word you’d use for an unaccellerated implementation which
all but pukes on itself the first time you try basic blending operations,
then sure it does. Yet SDL does not support this configuration. I can
only assume this is because nobody else actually believes it would be at
all worthwhile to support it. I personally can’t disagree since I tend to
measure OpenGL performance in frames per second as opposed to seconds per
frame.

Watch your wording. You said “almost no chance” as if to imply that the
world itself would stop spinning if it ever happened. Well, it’s happened.
I never said it wasn’t kludgy, wasn’t full speed and wasn’t full of hacks.
It isn’t vapour because it already exists. It isn’t a promise because I
and others are already working on it.

I never said I had manna from Heaven. The fbdri project is largely a gross
hack, but that doesn’t negate the fact that it does provide OpenGL on the
framebuffer. It had a hack for SDL so that it could be used from the SDL
fbcon backend. It was only one driver, the ATI Radeon, and it was largely
cut’n’paste from stock DRI. But it works.

I’m just trying to dispell the unfounded rumours you try to spread every
chance you get - that OpenGL doesn’t or never will run accelerated on the
framebuffer. It does, and support for it will get better as new APIs come
into place. I’m certain that when it does come into place, you’ll be one
of the first to sing praises to it - or you’ll complain that you could’ve
done it better yourself. Whatever.

If you said it’s crap today then of course I wouldn’t have bothered
responding.

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020125/9c72663d/attachment.pgp> On Fri, Jan 25, 2002 at 04:18:12PM -0600, M. R. Brown wrote: