Input device design

[Jon Smirl]

On 8/31/05, Joe Krahn <krahn at niehs.nih.gov> wrote:
> An "input device library" in this case would essentially be an X-Server
> module interface. That should be easy to implement, and very useful for
> debugging input modules.
> 
> I also think it would not become "mush" as long as the library client is
> willing to see input events described the way X clients see them.

An external implementation would need to be free of dependencies on
all of the X header files and data types.  I could see it running
either as a standalone process or as a library loaded into a main
process that has a thread captured inside of the library code. It
would be nice to have support for keyboard shift processing in the
external lib. You should also be able to the hard part of Asian input
conversion minus the GUI.

Once the event is digested it would need to go to the window manager.
The window manager will translate it to window space and forward it to
the appropriate process. It may need to repeat this until someone
wants the event. This model would let a standalone app receive the
input message without needing a window manager.

Could a single extensible message type handle all input devices? Or is
it better to have different message types for keys, motions, etc.

Gesture recognition would probably need to occur in the external input
library so there needs to be a way to communicate gestures in the
protocol.

It doesn't seem to me that the consumer of the input events (window
manager, standalone app, etc) needs to be aware of device hotplug
add/remove.

I would find a library implemented in a manner like this to be very
useful for external applications.

> Brian Paul wrote:
> >
> > I really don't know much about input devices and the issues for the X
> > server, but one thing is on my mind.  Would it be possible to create
> > an "input device library" that could be used both by the X server and
> >   other programs which don't use X?
> >
> > Consider that when we get the extended EGL stuff working, we'll have
> > an OpenGL environment that can be used independently of the X server.
> >     It would be nice to have a complementary input library.
> >
> > The upsides for such a library are obvious: reusability, modularity,
> > portability, versatility, etc.
> >
> > The downside is it could be over-engineered to the point where it's a
> > big, over-generalized, ambiguous pile of mush.
> >
> > Is something like this feasible?
> >
> > Looking at the big picture, an X server layered on EGL/OpenGL and such
> > an input library might not contain any device-specific code at all.
> >
> > -Brian
> >
> > _______________________________________________
> > xorg mailing list
> > xorg at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xorg
> >
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
Jon Smirl
jonsmirl at gmail.com