This is a summation of the discussion between the est. Bryan W. Headley,
the est. Egbert Eich and myself so far, along with a few new ideas...
OK. Most people seem to think we need a new way to do device handling of
what is currently called extended devices in X. I, as an applications
programmer, find that it is far too restrictive and very importantly
that the device drivers written for it do not sufficiently conform to
the documentation, and the device programmers find that it cannot
express all the aspects of a modern Human Input Device (or HID).
There are two choices: Either to fix the old broken API or to make
something new and phase the old API out.
In favor of fixing the old API is the fact that making a new one would
mean going over every driver to make them conform to the new API. This
is a large task. Besides, people know the old API.
In favor of making a new API and phasing the old one out are:
a) We can do it much better without being inhibited by any choices that
were made in the old one.
b) Because it's a new API it's easier to enforce the standard rigidly so
we don't get all that "I'm putting something different in the ->type and
->name field than you"-nightmare all over again.
c) People might know the old API but it's not exactly loved...
d) If we expand the old API, we probably still need to go over most
drivers.
As you might gather, I'm all for making a new API.
---
If the situation looks like this:
Applications
------------------
XInput API
------------------
Device drivers
------------------
Kernel
then there's no denying that my experience lies mostly in the two upper
parts. I also understand that Bryan is mostly down in the two lower
parts, occasionally sticking his head all the way up to Applications
level (correct me if I'm wrong, that's just the impression I got from
the correspondence). Since it's the primarily the API that's
ineffective, I suggest starting from there - that's also what we all
know something about. Summing up on the discussion so far, we want an
API with:
a) Hierarchial ordering of devices.
b) Hot-pluggability.
c) An extremely flexible interface for letting the application know what
the device is telling us.
d) The possibility to have communication back and forth between
device(driver) and application.
I propose that we simply start by defining the new API as a header file
(or set of header files). The first version might not look anything like
the finished result but we'll have something constructive to work from
and a common reference. I would be happy to make a suggestion which I
will hasten to say would *not* be my idea of how it should be but rather
some loose sketches on what it might be which we can then add to and
change as befits us. How does this sound?
---
And now for the rambling brain-storm part of the mail:
As regards the flexible interface, I was thinking... Practically all
devices actually send rather kinds similar information. I'm not sure
what a dataglove sends but a mouse basically sends a point and so do
tablets as far as I know - of course they're respectively relative and
absolute coordinates, but still. Joysticks actually send a 2d-vector
(which is [0, 0] when it's not touched), spaceballs send a 3d-vector...
All of them neat physical concepts.
Was it possible that upon opening the device, you could be told:
"When I'm sending you an event, it's going to be so-and-so long. There
will be x longs (or reals or whatever) of information, of which the
first two will be an absolute position, the next two will be button
states, etc. etc. A dataglove might send 20 or something 3d-points with
every event, one for each point on the glove. I know this is crude but
it is just to let you understand the general idea.
After all, the physical devices are real-world objects; what they put
into the computer is real-world information. If you can interpret 2d-
and 3d points and vectors and radians, what other kinds of measurement
are there, physically speaking? If we could only structure the
information in some way so that it's easier for the application to
understand...
The hierarchial structure might, in fact, help. Consider the dataglove
again. We could register the glove with each finder as a subdevice which
each measurement point along the finger as a subdevice again. Suddenly,
the structure of the information makes it much easier for the
application to understand the data...
Does this make any sense? Looking forward to your input,
/Claus
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
