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]