Andreas Beck wrote:
> > 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 don't think so. It's a matter of concern. The user doesn't necessarily have
control over that.
> > 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.
cool, we seem to be almost there. Now the only missing function is one that
lists all available attributes (name / value pairs). *That* is really just
convenience, but a nice wrapup of this whole feature.
> Again please excuse if I annoyed you.
you didn't. I like heated discussions, as long as they are constructive. I'm
well able to distinguish that from personal attack (which I didn't find in your
post).
Best regards,
Stefan
PS: and thanks to Brian for getting us back on track ;)
