If anyone has already worked on this idea in the past, I would be glad
to pick up where they left off rather than attempting to re-invent it.
If not, I will proceed on implementing it. Is there any demand for such
functionality in the libSDL community? Is anything like this planned for
Not specifically. We’ll be adding multiple mice support, but that’s
using the OS-level facilities and not a generic plugin interface.
Such is what I’ve seen in the code. For joysticks, it all depends upon a
set of SDL_SYS_Joystick* methods defined for the current platform. These
are used to generate a list of “available joystick descriptors”, from
which the application may then choose to read from.
The mouse, however, has a number of methods defined under
system-specific directories of the video/ subfolder. In addition, the
interfacing of the mouse seems to be taking the presence of a mouse in
the windowing system as a granted fact (a logical conclusion). The
multiple mice support is interesting, however. Does this actually
enumerate the individual mice into the app and then offer an API to
figure out which mouse generated events?
…but you can use SDL_LoadObject for a plugin system that pushes custom
events on the SDL event queue, using existing public SDL APIs. If you
want to make this robust and generic, it could be used as an add-on
library without changing SDL.
Yes, it very well could. This would, of course, be a possibility but
since changing the source to libSDL to allow dynamic loading of said
Joystick (and maybe mouse) drivers (and defining an API to do so) is an
easier task than doing all I just stated, plus creating something that
goes off and modifies the internal data structures (like the joystick
list) as a loaded function from a loaded shared library. I felt that
perhaps having a pre-defined API for loading specific types of dynamic
libraries might be valuable enough to warrant inclusion in the base
One thing I would like to avoid is having to maintain my own different
version of libSDL (with such an API in it). Taking the joystick as an
example, it would be much easier to modify SDL_joystick.c to provide
functions similar to SDL_SYS_Joystick* but, say, SDL_DYN_Joystick* or
SDL_EXT_Joystick*. These, rather than pulling from the system-specific
SYS code would instead rely upon a structure being set up by the
developer’s application with functions like
It would be programmed to look for “mytestjs.dll” on Win32, and
"mytestjs.so" on ELF-style systems, etc… It would then call some
defined function using SDL_LoadFunction(“EXT_JoystickGetDescriptor”) to
load the device description from the driver.On Wed, 2007-05-09 at 04:39 -0400, Ryan C. Gordon wrote: