Hi,
> why do you make such a clear separation between the 'system' and the 'user
> space' ? It's a user who runs and maintains the system, it's a user who
> wants to use the system's capabities.
Well - not always. I come a little from the Multi-user side here maybe.
> Berlin wants to be extremely flexible and adaptable. And of course, it's
> the user who should be able to adapt it. But to be able to do that, he needs
> to know the system. Berlin can't figure it out all by its own. I don't assume
> that drivers are just magically in place. I assume that berlin is run as
> a user program, is configured based on the feedback the user gets from the
> lower levels (if capability X is present, adapt berlin to use it for Y,
> if driver Z has version V, don't use it since it contains a bug, etc.)
O.K. - though IMHO it would be better to fix the underlying driver, but that
is a matter of personal preference.
> I do agree that these are not common tasks. Yet it has to be possible.
O.K. - agreed.
> > They shouldn't, or at least they should be implemented in streaming targets
> > to transparently get the needed info through the stream. Got to look at the
> > implementation to see if that happens.
> well, from the little insight I have into GGIs internals, it seems they don't
> have anything to do with events. ggi_input seems to be a node in a linked
> list, which is traversed by giiFindDeviceInfoByNumber.
Yes - however the contents of these structures are filled in by the device
drivers and the glue code that keeps the individual devices together via
well defined interfaces.
> If I understand that correctly, these gii_input nodes are always local,
Yes. Only events can come from remote sides and are then injected into the
local gii_input queues by an input that receives them, like the tcp-input.
> i.e. in case of a multi-process system you'd probably have the same
> node in both processes, so you can forward events between them.
Yes - almost. One side has an event server attached, on a client.
> That's perfectly fine. All I propose is to add more (heap allocated) data
> to the gii_input structure,
O.K. - that is not a problem, as long as this data can be filled in over
remote connection, i.e. there at least exists a way to tunnel it through
events or something. Otherwise you loose the nice transparency to be able
to e.g. route all input devices to a central hub which then allocates
devices for individual users on a multihead setup etc.
> i.e. extending either the devinfo, or if that doesn't work (because
> the same structure is used as parts of events, too, add an
> 'extended_deviceinfo' member to it.
I would prefer to be able to - thanks for that suggestion to Brian - say
query an "attribute" of a given input.
That is - a call along the lines of
"giiGetInputAttribute(input,origin,char *attrname,char *attrreturn,int maxattrlen);"
This allows to have any arbitrary strings that can be queried efficiently
and no need to support them all in all drivers. As the transport mechanism is
abstracted, then, it doesn't hinder transparency and efficiency.
CU, ANdy
P.S.: Please excuse if I got personal in previous posts. I was quite a bit
annoyed this morning about making so big a deal of a feature that is needed
in so few situations and seemingly even being willing to throw away a system
that is perfectly good for 99.9% of the cases just to get that 0.1% more
functionality at the expense of 100% more complexity. If the above solution
fits your needs, that will give the 0.1% with only 2-3% extra complexity,
which I can stand :-).
Again please excuse if I annoyed you.
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
