Andreas Beck wrote:
>
> > How often I use that is totally beside the point. The fact is that users
> > want to configure their input devices.
>
> See below - what help is it ? You get so much data, that you get lost in it.
> How does that help to configure it ? I rarely read more than the first 10
> chars of a device description to judge which device it is and what functions
> to assign to it.
>
> > because different revisions might support different capabilities.
>
> It's not the job of the user to know that. It's the job of the driver. If it
> has a capability and the user knows, but the driver not - what is gained ?
> He can't use it anyway.
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.
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.)
I do agree that these are not common tasks. Yet this stuff has to be possible.
> > And, how do the functions you pointed me at relate to this discussion ? I.e.,
> > don't they assume random access memory, i.e. as in a local address space ?
>
> 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.
If I understand that correctly, these gii_input nodes are always local, 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.
That's perfectly fine. All I propose is to add more (heap allocated) data
to the gii_input structure, 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.
Regards,
Stefan
