You might want to look at the generalized input model provided by X for
some historic perspective on the problem.
One way to look at every input device in the world is as a set of finite
state and infinite state sub devices.
Finite state devices include things like buttons, switches and knobs with
a fixed number on positions. A key on a key board is a finite state device
with two possible values (0 and 1) which you can map to pressed, released or
what ever. A knob with 10 positions is a finite state device with 10
possible states (0,1,2,3,4,5,6,7,8,9). A shaft encoder on a stepper motor is
also a finite state device, but it is likely to be treated as an infinite
state device.
Infinite state devices are things like variable position knobs, the x, y
values from mice, and the deflection values for joysticks. An infinite state
device returns one of an infinite range of values usually mapped to the
range 0-1 before it is delivered. Infinite devices come in two types,
relative and absolute. So, a tablet puck would report absolute positions
while a mouse would report relative changes.
In this model a device is a named “thing” that has a set of finite and
infinite state units associated with it. So, a keyboard is an array of 100+
two state devices. OTOH, a mouse is a set of 2+ finite state devices
representing the buttons and 2+ infinite state devices representing the
motion axes and the wheel.
In this model all devices have a device descriptor record that tells you
the name of the device, the number of each type of sub devices, their value
ranges, and their names.
My mouse would be described by a record containing the following"
Device ID: N
Device Type Name: Mouse
Number of finite devices: 3
Finite device 0:
Name: button0
Range: 0,1
…
Infinite device 0:
Name:x axis
Mode: Relative
Range: 0-1
…
Infinite Device:2
Name: Wheel
Mode: relative
Range:0-1
And so on.
At the bottom level an event always reports a change in state. An event
would contain the ID of a device descriptor, the index of the sub device and
the new value or the relative value of the sub device along with the time
the change was reported. For simplicity each sub devices change would be
reported as a separate event even though several thing may have changed at
the same time. From experience I can tell you that putting multiple value
changes in single events is not easy to work with.
Generally there would be a function that would let you query the classes
of devices available on the system and to query for the device id of the
"standard" keyboard, mouse, and so on.
I think you will find that just about every input device and every
combination of input devices can be described using this approach.
One thing you do not want to do is tie input device models to things like
the cursor. In a generalized application there is know reason why I can’t
have several cursors all tied to different input devices and processes. I
should be able to tie a input to a cursor as I please and when I please.
Bob Pendleton
On Wed, Jun 4, 2008 at 11:58 AM, Edward Cullen <eac203 at ecs.soton.ac.uk<mailto: eac203 at ecs.soton.ac.uk>> wrote:
A while ago, I started thinking about the differentiation between
mouse, keyboard and joysticks.
Maybe it came from seeing stuff about multi-mouse and similar ideas.
I wonder if there would be advantage in creating an abstract
interface layer, of which, mouse, keyboard, joystick, were
particular instances (perhaps templates created for convenience?)
With the exception of the keyboard (which is generally
standardised), mice and joysticks come in all sorts of shapes and
sizes (number of axis and buttons), so, should one want to use a
device to it’s full, one is forced to query the device in some way
to establish its capabilities.
My starting point is the classification of capabilities.
Clearly, buttons are 2-state switches.
Joysticks are generally 2 to 4-axis absolute motion devices.
Hats can be considered as a set of switches, as an n-state switch or
even as a set of binary axis.
Mice are interesting.
Simple mice can be treated as either a 2-axis relative motion
devices, or as an absolute motion device (i.e. cursor).
Tablets, again, can be treated in different ways:
2-axis absolute, 1 switch.
2-axis relative, 1 switch.
2-axis relative, 1-axis absolute.
3-axis absolute.
It seams to me to make sense to separate the cursor location (i.e.,
treating the mouse as an absolute motion device) from all-other
forms of input and to create an interface that doesn’t differentiate
between input sources, only how they are treated.
Eg.
SDL_Mouse becomes SDL_Cursor
SDL_Joystick becomes SDL_InputDevice
Initialisation of a mouse as a relative-motion device might then be:
SDL_InitDevice(DeviceID, DeviceDescription, bool generate_events)...
with DeviceDescription being something like:
typedef struct {
axis_type axis[8];
int button_types[32];
} DeviceDescription;
where axis_type is one of {none, binary, absolute, relative} and
button_types is one of {0, 1, 2…n}, 0 being off, 1, being 2-state
and 3+ being interpreted as a hat.
Clearly, this is incomplete, but hopefully enough to generate useful
discussion…
The key advantage I could see is that ‘new’ device types wouldn’t
need adding to SDL, they would ‘just work’ as long as there was some
internal mechanism for enumerating all input devices reliably…
Thoughts?
Eddy
P.S. I imagine that this is similar to something else out there, but
I haven’t really investigated thoroughly.
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±-------------------------------------+
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
