From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Tue, 22 Sep 1998 01:23:28 +0200 (MEST)

Re: Events and Joysticks

Hi !

[I'm a bit sleepy right now, hope I don't mix too many things up :-) ...]

> 1. Joysticks use `evValAbsolute' events, which look like this :

> Note that I replaced `changed' with `count'.  That `changed' field in the
> old one was a real bitch.  Much more complexity (making both generating
> and using these events harder) without any benefit as far as I can see.

Yeah - the idea was to save bandwidth, in case "sparse" reportings are
common. Hoever I am not sure, if this is the case very often.

I think most devices will either send single axis one-by-one or all
of them or a group of them, thus giving the same size with both schemes.
Only when some axis are missing between other reported axis, the old
thing makes sense. So: I like your change.

> 2. Joysticks are described by an initial `evValInfo' event (or multible
> events) that LibGGI automatically generates at start up.  This describes
> the kinds of values that appear in ev.val.value[N], as well as the total
> number of values.  

Yes. With GGICon we could dynamically ask for those, but for now I think a 
device should just queue such an event at giiOpen()-time.

If you really need to reget the info, just reopen the device.

However I have a slightly different idea about implementation:

- typedef struct ggi_valinfo_event {
+ typedef ggi_deviceinfo_event	
# I want to split into one kind for the devices, and then one for val-axis

=         COMMON_DATA;
Yep - used to identify the device using the dev-ID (we nee to fix that in
the gii-code IIRC most devices send 0 here up to now except in EvStack).

Now for the differences:

+ 	char	shortname[5];
Holds a short handle for the device suitable for display in config-screens.
Something like Joy1, Kbd2, Tab1, Mou3.

+	char	longname[80];
Something more descriptive. Maybe "Networked input-tunnel from blubb.bla.com".

+	ggi_ev_mask	will_generate;
Types of events that the device can emit.

?         ggi_input_type  dev_type;   /* type of device */
Maybe - might make sense for "auto-config" and such.

Now each device sends yet another message describing its valuators (one per
valuator):

+ typedef ggi_valinfo_event {

=       COMMON_DATA;
+ 	char	shortname[5];
+	char	longname[80];

-         uint32          first;      /* first valuator reported */
+         uint32          number;     /* number of current reported valuator */

-         ggi_value_type    val_type;    /* type of valuator */
-         uint32            range;       /* (depends on val_type) */
+	struct range { int min,center,max; } range ;
This takes care of GGI_VALTYPE_CENTRED and GGI_VALTYPE_BOXED.
DELTA is handled by sending Rel events (which could e.g. be asymmetric or
even 0-max - an example might be an hours-of-operation counter.).

The idea is, that every application should take Rel- and Abs-events
for anything.

> (In fact, all that suggests just one event `evValuator' would be
> enough... I don't know).

There might be devices that usually are absolute, but sometimes use a 
realtive mode. Military positioning/tracking/guiding sensors are such 
a thing. They usually use GPS to get an absolute position, but if that
for some reason fails, they fall back to inertia-navigation, that gives
relative info. Similar devices are e.g. relative length sensors (which
are cheap compared to absolute ones), which have a special detectable
"zero" position that makes them effectively absolute devices, if you
drive the device over the zeroing mark before starting measurement.

> (Possibly ggi_value_type values could be OR'd with other sets of values
> to indicate stuff like force vs linear etc...  food for thought).

+	enum physical_quantity_measured { length, force, temperature,
        current, angle, ... } phystype;

eventually (I'm into physics, so :-) :

+	"double" factor_from_event_units_to_common_SI_unit;
(where we should probably "fake" the double to avoid floating point.)

> 3. Joystick buttons use `evValButtonPress' and `evValButtonRelease'
> events, which look like this :

This I don't like. What makes those different from keyboard keys ?
Just create KEY_BUTTON(x) and be done with it.

I'd like not having to write yet another switch-case in case a user
configures "fire-secondary" to both JoyButton2 and Keybord-Rightarrow.

> The old way was to just use key events, but having tried that I really
> disliked it.  The KT_BUTTON thang was an ugly hack, which just got in
> the way of normal keyboard usages.  

Why ? It has its own range, and no symbol. Just a label. It doesn't do more
harm than the Ctrl-Key.

> And non-keyboard devices don't need all that sym, label, & modifier stuff.

sym is usually kept clear (though someone might _want_ to put a few
keystrokes like <Esc> and <Enter> on a 10-button spaceball ...), and the
modifier _might_ be useful. 

> IMHO evValButtonPress/Release is a much cleaner and more consistent solution.

IMHO to the contrary. It is yet another event type that needs to be parsed
differently. If you can get all using just keys and valuators, this means
less code that can break or be forgotten, because the author doesn't need
it. And it forces people to do parsing and configuration stuff right.

If some game has a yes-no control like "fire", why should it make a
difference if I map it to the keyboard or to some button on the jostick ?
It just jets mapped to some binary switch.
(I know some joysticks make up the hatswitch with 5 positions of an axis.
 However I think these should be converted to "buttons" by the driver.)

> OK, that's it.  Andy, what do you think ?

See above ...

Cheers, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =