> 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.
> And as soon as I'm able to take advantage of these advanced capabilities,
> the user might want to know whether the device can do X or Y.
If it can do, it must be represented in some kind of event, and if it is,
you can query that using the getvalinfo and friends.
> I'm not suggesting that people have to deal with that stuff. But a powerful
> windowing system that can be configured to take advantage of arbitrary devices
> has to be able to present the necessary info to the user.
Right - the necessary info. And if the generic info gathering mechanisms
don't collect enough data, you won't be able to interpret the incoming
events lateron anyway.
> > Do you _really_ think that this is a problem _in_practice_ ? From an
> > academic point of view, it surely is, but ...
> yes I do. You sound like software engineers twenty years ago, pointing out
> that two positions are enough to represent a year.
Actually that wasn't a sooo bad idea as the Y2k hype wanted to make us
believe. Using a window technique it is appropriate for most data, as it
rarely has interest spans beyong 100 Years. But that's beside the point.
> that is hackish. Of course, with fixed size events that's the way to go.
> But why use events in the first place ?
Because you loose network/process transparency if not.
E.g. how do you query the devices attached to a cube3d from a process
running on its side ? They are in a different process space. You can't call
out and just get back some alloced mem.
> hmm, I don't really care for network transparency at this point.
I do. count me out of GGI, if that doesn't work anymore. I use it, I need
it, and I don't want to break it for something that IMHO is a debugging
issue.
> of network transparency is rather poor on this level
I will not discuss this topic.
> no, of course not. See how complex CORBA's resource management is to deal
> with resources in a location transparent way.
*nod*.
> It is funny, as you pretend that only few people would be interested into the
> kind of 'extension' I have in mind. How many people do you think have to pass
> events through streams ?
The idea for stuff like KGI, EvStack etc. was, that everyone would do that.
I.e. he would just open /dev/event[tty].
However I don't really care. Do whatever changes you seem fit. I have a
current CVS snap and I have local CVS capabilities to keep me a separate
tree.
> 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.
Have fun,
Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
