Index: [thread] [date] [subject] [author]
  From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Sat, 19 Sep 1998 13:05:29 +0200 (MEST)

Gii integration (was shmem integration)

Hi folks !

> So - is it possible to control how memvisual handles keyboard/mouse/etc?
> as in - if some environment value is set (or a parameter), read from a
> pipe (of some kind) or set of pipes [keyboard, mouse, ...]

No. You bring up a very valid point here. We didn't do much about input
handling, and I think there is room for improvement, and we should do it
now (it's easy) to avoid bringing something out that brings back trouble
later.

The idea is the following :

Have a gii_input_t that describes _all_ attached input systems.
This is done by making it a linked list, what allows to attach/detach
event sources as required.

To keep compatibility, I suggest to add an entry

	gii_input_t visinput;

to ggi_visual_t and replace the stubs for the input handling by

ggiSomeInputFunc(vis,...)
{
	return giiSomeInputFunc(vis->visinput,...);
}

This "general input interface" functions should be integrated with LibGGI,
as they will be rather simplistic.

The idea is, that going this path allows for seamless integration with the
current implementation.

Current target will override the ggi-input functions, thus giving old
behaviour.

We can then port them step by step to filling the visinput instead.

I expect the visinput to look something like

struct visinput {
	struct visinput *prev,*next;
	int select_fd;
	ggi_event_mask curreventmask;
        ggi_event_mask (*eventpoll)(gii_input_t inp,
                                    ggi_event_mask mask,
                                    struct timeval *timeout);
        int (*eventread)(gii_input_t inp, ggi_event *ev, ggi_event_mask mask);
        int (*seteventmask)(gii_input_t inp, ggi_event_mask mask);
	int (*destroy)(gii_input_t inp);
}

That is basically the same as before. Only that the select_fd is per
input source (thus allowing for multiple select fds) and that we have
a destroy function, which comes in handy for getting rid of unneeded 
input sources.

For the new gii functions, I'd suggest :

The usual  giiEventPoll, giiEventRead, giiSetEventMask, giiGetEventMask
The macros giiAddEventMask(vis,mask), giiRemoveEventMask(vis,mask)

And a bunch of new functions that deals with managing gii_inputs.

gii_input_t giiOpenInput(char *driver,...);
{
	basically copy much of that from ggiOpen(); ...
}

int         giiCloseInput(gii_input_t *inp)
{
	/* Unlink it */
	if (inp->next) inp->next.prev=inp->prev;
	if (inp->prev) inp->prev.next=inp->next;
	inp->destroy(inp);
}

gii_input_t giiJoinInputs(gii_input_t inp, gii_input_t inp2)
{
	/* Link in the inp2 chain after inp */
}

This way, we can structure our input system a lot better, because we
can write independent modules say for /dev/joystick.

So e.g. the X target which will usually have no clue about that one,
can detect if it is running on Linux (actually it can leave detection 
to the gii module) and simply call

joy=giiOpenInput("joystick",NULL);
if (joy) gii_JoinInputs(vis->visinput,joy);

Would be nice, wouldn't it ?

Comments, please !

CU, Andy

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

Index: [thread] [date] [subject] [author]