Input device design (3)

Joe Krahn krahn at
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 mailing list