CVS Update (driverlist + aRts + 1.1.7 prerelease)

Pete J Shinners wrote:

static const char* driverlist[] =
{
#ifdef DRIVER1
"driver1",
#endif
#ifdef DRIVER2
"driver2",
#endif
#ifdef DRIVER3
"driver3",
#endif
NULL
};

static const int numdrivers = sizeof(driverlist[0])/sizeof(driverlist) -
1;

I think that should be:
static const int numdrivers = sizeof(driverlist)/sizeof(driverlist[0]) - 1;

Otherwise you’re going to end up with 0 or a negative number. ^,^

Of course, that was most likely a typo, and you knew what the correct way
was, and so does everyone else who read your mail, but it’s late (early),
so I can have no sense and point silly stuff out if I wanna. :stuck_out_tongue:

Cheese!

Sean Etc.

“She turned me into a newt!” “A newt?” “My lawyer made it better…”

Nope. strncpy() doesn’t seem to have consistent behavior. On Linux,

strncpy does not zero-terminate if strlen(src) >= n. It’s the subtle
behaviour that most people don’t realize when they use strncpy.

m.–
“Advocating a system based on consumption is the ultimate violence
against poor nations.”
-Masamune Shirow

strncpy does not zero-terminate if strlen(src) >= n. It’s the subtle
behaviour that most people don’t realize when they use strncpy.

strncpy works on a old-fashioned data structure which isn’t in current use:
the fixed-width, zero-padded string buffer. The padding is mostly
a waste of cpu. Better do something like

void mystrncpy(const char *dst, const char *src, int size)
{
int len = strlen(src);
if(len > size) len = size;
memcpy(dst, src, len);
dst[size - 1] = ‘\0’;
}

strncpy can still be useful when dealing with certain disk formats and
network protocols

  1. int SDL_NumVideoDrivers( void );
  2. const char* SDL_VideoDriverName( int driver );
  3. int SDL_SetVideoDriver( const char* driverName );

Much better, and we still keep the door open for SDL_GetDriverCaps(int driver).
Add a param to indicate driver kind (audio, video, input, olfactory etc)
and we don’t need a separate set of functions for each category

I’d prefer the driver name to be identifying rather than descriptory
(“fbcon” rather than “Linux Frame Buffer Console”) if they are used in
the third role (setting a driver). We can still provide a longer description
string in the caps:

struct SDL_DriverCaps {
char *name;
char *description;
union {
SDL_VideoDriverCaps vid;
SDL_AudioDriverCaps aud;
SDL_InputDriverCaps inp;
SDL_SmellyDriverCaps olf;
} un;
};

As long as the system isn’t abused then it should be fine and its a lot better
than people using setenv(“SDL_VIDEODRIVER”, “blah”). However, maybe the
SDL_VIDEODRIVER environment variable should still be respected? If its set
then the only video driver reported is what it specifies.

We want both the game’s preferences (“want a video driver with hardware
surfaces”) and the user’s (“use a driver that doesn’t crash my machine,
you spawn of c++”).

You suggested on #sdl a while back some kind of config file system
(/etc/sdlconfig, ~/.sdlconfig): Let the user specify a set of drivers to
use, in order of preference, and only those would be exposed to the
program. Both global and program-specific options would be possible:

; default driver preferences
(any
(video-driver fbcon dga x11 aalib)
(audio-driver alsa oss esd)
(config input (joystick-device “/dev/input/js0”)))

; specifically for maelstrom (i.e. fbcon is undesirable)
(maelstrom
(video-driver dga x11))

; set both desired audio and video drivers
(gltron
(video-driver x11)
(audio-driver oss))

; ask for a particular refresh rate to better match the emulated target
(snes9x
(video-driver dga)
(config dga (vertical-refresh 60)))

The environment variables could then be used to override these settings

Thu, 14 Dec 2000 Sam Lantinga wrote:> > On Wed, Dec 13, 2000 at 09:21:45PM +0100, David Olofson wrote:

Hmm… How about doing the GetFirst() + GetNext() function calls now, returning
pointers to structs that for now just have the name fields defined in the API

I only see three necessary functions:

  1. int SDL_NumVideoDrivers( void );
  2. const char* SDL_VideoDriverName( int driver );
  3. int SDL_SetVideoDriver( const char* driverName );

That what CVS releases and development branches are for. :slight_smile:

Thanks for the suggestion. I’m more than happy to do it that way,
but the current code lists only available drivers (instead of all of
the drivers compiled in), and lists them in order of preference.

FYI, all sorts of wild ideas are flying through my head about what
to do for SDL 2.0, as sort of a “now I can do it right” release.
This would of course involve lots of API improvements and large
backward incompatibilities. Maybe the whole driver listing API
should wait until then…

Comments?

As I see it, the question is

Can we get the basics right, *now*?

If not, there’s not really much point in messing with it now, as it would still
have to be replaced with whatever comes up for 2.0.

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Wed, 13 Dec 2000 Michael Vance wrote:> On Wed, Dec 13, 2000 at 09:21:45PM +0100, David Olofson wrote:

Hmm… How about doing the GetFirst() + GetNext() function calls now, returning
pointers to structs that for now just have the name fields defined in the API

I only see three necessary functions:

  1. int SDL_NumVideoDrivers( void );
  2. const char* SDL_VideoDriverName( int driver );
  3. int SDL_SetVideoDriver( const char* driverName );

Well, the whole point with the posts I was commenting on was that this would not
be enough, and thus, this API would soon be obsolete.

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Wed, 13 Dec 2000 Florian ‘Proff’ Schulze wrote:

This is kinda’ nice though. However, it may appear less nice when considering
that an array cannot be dynamically resized. (OTOH, would that ever be
needed?)
Another problem is that elements in a vector must be of fixed size, which
means
that SDL cannot strap private things onto these device structs without
breaking
the API on the binary level.

An array of pointers would be nice, though, but
if it’s a copy/“special thing” that’s generated by the SDL call, someone has
to
delete the array as well.

Also, you need to know the size of the array…

What about linked lists?

Well, that’s basically what I’m suggesting, although my implementation would
encapsulate that inside the GetNext(node *) call. One might decide that a
linked list is simple enough to hand out to the user without encapsulation, but
I don’t know if that’s a really good idea…

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Thu, 14 Dec 2000 Martin Donlon wrote:> On Wed, Dec 13, 2000 at 07:52:30PM -0800, Sam Lantinga wrote:

My only worry is that this system takes the driver choice away from the user.

What system?
Driver selection API.

I’m confused. I’m assuming that this API is only used in special cases
where the application knows for absolute fact that it is in a certain
environment and requires a particular driver. Perhaps this kind of API
shouldn’t be exposed at all at this point, and leave the current
environment variable system in place until a more complete driver
capability and selection API can be designed.
As long as the system isn’t abused then it should be fine and its a lot better
than people using setenv(“SDL_VIDEODRIVER”, “blah”). However, maybe the
SDL_VIDEODRIVER environment variable should still be respected? If its set
then the only video driver reported is what it specifies.

Hmm… How about a special SDL_FORCE_VIDEODRIVER variable for that, so that the
old one can stil be used as a default for applications that don’t use the
driver selection API?

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Thu, 14 Dec 2000 Sam Lantinga wrote:

My only worry is that this system takes the driver choice away from the user.

What system?

The only way a user has of disabling a certain driver is by not compiling it
in. While this might be fine for people who compile SDL themselves, its not
that great for people who use precompiled libs or for people shipping
precompiled SDL’s with software (e.g. you:). Some drivers that may seem
superior,such as DGA or fbcon, are often buggy.

I’m confused. I’m assuming that this API is only used in special cases
where the application knows for absolute fact that it is in a certain
environment and requires a particular driver. Perhaps this kind of API
shouldn’t be exposed at all at this point, and leave the current
environment variable system in place until a more complete driver
capability and selection API can be designed.

How about keeping the environment variable as the default for applications that
don’t bother with the new API, and then strongly recommend that an application
that does use the new API also provides a way for the user to override or
disable the application’s “auto selection” if desired?

For example:
* Application A doesn’t use the new API, and thus gets the default
selection as of the current SDL implementations.

* Application B does use the new API, and normally selects drivers
  according to it's own preference, regardless of the environment
  variable.

  Application B is flawed.

* Application C does what application A does, but has a config file
  entry where the user can fill in "defalt" (default or environment
  variable), "fastest" (unless it crashes...), "safe" (should work
  on anything) or the name of the driver he/she wants to use. There
  is also a command line switch that overrides the config file
  entry.

  Application C is nice and well behaved. :-)

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

But, as Mike pointed out, its pretty hard to implement a system like this in a
cross platform manner. Plus, as I said before, with the limited range of
drivers it just seems like overkill. I think, let the application pick what it
thinks is best. That shouldn’t cause many problems, but if it does there is
always the SDL_VIDEODRIVER override to fall back on.On Thu, Dec 14, 2000 at 12:22:17PM +0100, Mattias Engdeg?rd wrote:

As long as the system isn’t abused then it should be fine and its a lot better
than people using setenv(“SDL_VIDEODRIVER”, “blah”). However, maybe the
SDL_VIDEODRIVER environment variable should still be respected? If its set
then the only video driver reported is what it specifies.

We want both the game’s preferences (“want a video driver with hardware
surfaces”) and the user’s (“use a driver that doesn’t crash my machine,
you spawn of c++”).

You suggested on #sdl a while back some kind of config file system
(/etc/sdlconfig, ~/.sdlconfig): Let the user specify a set of drivers to
use, in order of preference, and only those would be exposed to the
program. Both global and program-specific options would be possible:

; default driver preferences
(any
(video-driver fbcon dga x11 aalib)
(audio-driver alsa oss esd)
(config input (joystick-device “/dev/input/js0”)))

Martin

Bother! said Pooh, as he erased his hard drive

But, as Mike pointed out, its pretty hard to implement a system like this in a
cross platform manner.

only where to store the config files should be platform-dependent

Plus, as I said before, with the limited range of
drivers it just seems like overkill

Very possibly. We could augment the environment variables to contain
several alternatives (SDL_VIDEODRIVER=“dga:fbcon:x11”), and possibly
exclusions (SDL_VIDEODRIVER="!svgalib"), to let a game use the caps
for picking a driver

Nope. strncpy() doesn’t seem to have consistent behavior. On Linux,

strncpy does not zero-terminate if strlen(src) >= n. It’s the subtle
behaviour that most people don’t realize when they use strncpy.

n in this case is 1024. I’m pretty sure all the strings are shorter
than that. :slight_smile:

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Okay, I’m convinced. I’m pulling the API until SDL 1.3.
In the meantime you can use the standard environment variables to select
a particular driver if you absolutely need it.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Thu, 14 Dec 2000 Sam Lantinga wrote:

Nope. strncpy() doesn’t seem to have consistent behavior. On Linux,

strncpy does not zero-terminate if strlen(src) >= n. It’s the subtle
behaviour that most people don’t realize when they use strncpy.

n in this case is 1024. I’m pretty sure all the strings are shorter
than that. :slight_smile:

Uh oh… But they did get memcpy() right, at least, I hope…! :wink:

Seriously,

"DESCRIPTION
The strcpy() function copies the string pointed to be src
(including the terminating `\0’ character) to the array
pointed to by dest. The strings may not overlap, and the
destination string dest must be large enough to receive
the copy.

   The  strncpy()  function  is similar, except that not more
   than n bytes of src are copied. Thus, if there is no  null
   byte among the first n bytes of src, the result wil not be
   null-terminated."

and later:

“CONFORMING TO
SVID 3, POSIX, BSD 4.3, ISO 9899”

What platform where we talking about here? (If it doesn’t bother complying
with any of the above, I mean…) Or are the GNU man file lying or something?

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Sam Lantinga wrote:

Nope. strncpy() doesn’t seem to have consistent behavior. On Linux,

strncpy does not zero-terminate if strlen(src) >= n. It’s the subtle
behaviour that most people don’t realize when they use strncpy.

n in this case is 1024. I’m pretty sure all the strings are shorter
than that. :slight_smile:

AFAIK, this is to prevent stack overflow attacks to hack the system,
sending a longer string with some binary code after these 1024 bytes,
running a /bin/sh as root. but I am not a cracker, and I could be wrong.–
signed
derethor of centolos