Input device design (3)
krahn at niehs.nih.gov
Fri Sep 2 12:02:28 PDT 2005
Christoph Hellwig wrote:
> On Thu, Sep 01, 2005 at 09:37:09AM -0400, Joe Krahn wrote:
> > I think we can agree not to send events through an extra level of IPC,
> > except in the case of a remote or virtual devices.
> > I like the idea of an I/O library. Consider a library of I/O handlers
> > that packages events using an X-centric view, but still rather generic.
> > An X Input loadable module is then built by combining the code for X
> > server integration with the I/O code from a static library. This
> > minimizes the I/O libraries knowledge of X. The same code can then be
> > used shared or static by non-X programs.
> > Does that sound like a good plan?
> At least for Linux that's total overkill. Linux has a proper input
> layer, and you can access all input devices through /dev/input/event<N>
> or a wide variaty of emulations for old device nodes (/dev/psaux,
> /dev/js<N>, /dev/ts<N>), and thanks to uevent you can even feed it
> input events from userspace. No need to reinvent the wheel here, just
> add a new input driver for linux that can use these and translate them
> to normal and XInput extension X input sources. Other OSes still keep
> their old input drivers or if they have a similar input layer implement
> a driver like that. If there's enough common code though OSes refactor
> that into a common library in the X server later.
Yes, but Linux input is an OS-dependent API. So, in the Linux case, most
of the Input Library mentioned here would just be an interface to Linux
More information about the xorg