Interest in loadable driver API for input

SDL Development
1

Hello,

I am interested in developing an API for run-time loading of
shared-object input device drivers. I know that SDL typically uses the
OS to provide a HAL for such devices as keyboards, mice, and joysticks.

However, there are some devices which have a specific application and
for any number of reasons may not be interfaced at the OS level as a
mouse, joystick, or keyboard abstraction. I am working with one such
device, and I am curious if any prior work has been done in putting
together a run-time loadable driver API in SDL.

I have seen the existing SDL_LoadObject, SDL_LoadFunction, and
SDL_UnloadObject interfaces that abstract the “dlopen” features of the
host platform. In addition, I have seen the run-time loader for video
drivers on Intel’s website.

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
v1.3 ?–
Coleman Kane
IntelliTree Solutions llc.

2

Hello,

I am interested in developing an API for run-time loading of
shared-object input device drivers.

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
v1.3 ?

As per usual, I’m sure Tux Paint could (eventually) take advantage of it. ;^)
I’ve heard about some exotic devices out there (e.g., some “Vtech” kids’
drawing device that someone wished they could use with their PC and
Tux Paint).

Of course, I probably wouldn’t be writing drivers, and would prefer
proper drawing tablet (i.e., pressure sensitivity and eraser) support at
the SDL API level, but beggars can’t be choosers. :)On Tue, May 08, 2007 at 09:50:08PM -0600, Coleman Kane wrote:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

3

Hello !

That special input devices you are talking
about, do they have the same kind of drivers
with the same API ?

CU

4

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
v1.3 ?

Not specifically. We’ll be adding multiple mice support, but that’s
using the OS-level facilities and not a generic plugin interface.

…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.

–ryan.

5

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
v1.3 ?

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
product.

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
SDL_EXT_JoystickLoadDriver(“mytestjs”), etc…

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:

–ryan.

–
coleman