Input Devices (was: Re: [Xgl/Xegl] Input Devices )

[Jim Gettys]

On Wed, 2005-07-27 at 17:46 +0200, Waldo Bastian wrote:
> On Wednesday 27 July 2005 09:51, Dane Rushton wrote:
> > Hi,
> >
> > I've been researching this over the last week or so (spare time only - I
> > work full time) and have read the XInputHotplug page and your paper on
> > http://www.linuxsymposium.org/2005/ .
> >
> > Having just finished reading the thread between Kristian, Keith and
> > yourself
> > (http://lists.freedesktop.org/pipermail/xorg/2004-August/002054.html)
> > from last August, it looks like most of this has been discussed before.
> > Though last time the conversation appears to have stopped abruptly
> > without much resolution.
> > Lets get that going again!
> 
> Yes, note that there is also:
> http://wiki.x.org/wiki/XHotplugProposal
> http://wiki.x.org/wiki/XInputHotplug
> http://wiki.x.org/wiki/XInputSpec
> http://wiki.x.org/wiki/XOrgInputDriverSpec
> 
> > I think we all know what kind of high level features are wanted. So lets
> > discuss possible implementation ideas.
> >
> > Ok some points to discuss:
> >
> > 1) Expand XInput into XInputHotplug? Any real progress here?
> > 	Advantages:
> > 	Disadvantages:
> 

We need:
	o The ability to notify clients of devices coming and going,
	o better abstract naming of valuators
	o might need more than 255 devices (device ID's are char's in the
protocol, unfortunately), though this depends on how the multi-user
stuff gets done.  I'd claim 255 is enough for a single user, so if a
user's ID is encoded external to the input events somehow, the current
field may be sufficient.

It isn't entirely clear yet whether incompatible changes need to be
introduced into the XInput wire protocol or not; I suspect not, but
there may be some gotcha someplace.

> * Having server specific options as part of XAddInputDevice is considered a 
> bad idea, see 
> http://lists.freedesktop.org/archives/xorg/2004-August/002055.html

> * It seems there is some concensus that it may be better to handle device 
> addition via a mechanism other than XAddInputDevice, see
> http://lists.freedesktop.org/archives/xorg/2004-August/002097.html
> and http://wiki.x.org/wiki/XHotplugProposal
> 
> An open question seems to be wether DBUS would be a suitable IPC mechanism for 
> that. One of the proposals so far is to have the configuration client open 
> the device and pass it's file descriptor to the X server (see 
> http://lists.freedesktop.org/archives/xorg/2004-August/002104.html ) DBUS 
> doesn't seem to provide that at the moment. If that's considered the way to 
> go then either fd-passing needs to be added to DBUS or a different IPC 
> solution would be needed.

It probably is better to use DBUS, for much of it, though we'll have to
figure out some way to send the file descriptor.  The issue here is that
the current internals of the X server do no have the ability for the X
server to become a client of another server (in this case, DBUS); it
might deadlock.

So there is housekeeping work to do here; redoing a better, general
mechanism will also enable cleaning up a lot of gross hacks that have
accumulated over the years.

It's probably a few weeks or a month's work to build this new internals
module to replace the current select/poll mess inside the server.

> 
> > 2) Use HAL over other hardware detection mechanisms?
> > 	Advantages:
> > 	Disadvantages:
> 
> On linux HAL and udev seems the most logical solution. HAL isn't available on 
> all OSes but there is nothing that stops anyone from implementing HAL for 
> their OS. With an external configuration client it would be that client that 
> would depend on HAL.

Not clear that X itself has to know about HAL: clearly a UI "plumbing"
program to attach a input device to the X server might want to know
about HAL.

> 
> > 3) Use EVDEV as primary input driver interface? My preliminary research
> > of EVDEV leads me to believe this is a powerful and useful mechanism.
> > 	Advantages:
> > 	Disadvantages:
> 
> In http://lists.freedesktop.org/archives/xorg/2004-August/002097.html Jim 
> identifies three cases:
> > There would likely be three such filters (on Linux):
> >  a) existing serial devices (if we care)
> >  b) evdev devices.
> >  c) remote devices via some (yet to be determined) wire
> >     protocol.
> 
> For c) I imagine that the evdev protocol can be mapped relatively 
> straightforward on some sort of wire protocol. Mostly a matter of moving the 
> ioctl calls in-band? Will also allow user-space drivers.

Yup. And network devices are needed for the SNAP case, per my OLS paper.

2.6 has translation for alot of old serial devices to the evdev
interface.  I suppose we could do a user space module that did this
translation, if we must.  But let's just go with USB HID devices to get
started.

We may want to look into a more interesting/OS neutral extensible
encoding for input events (which don't go that fast).  I've been
seriously tempted to go the XML route.
http://www.w3.org/TR/2001/WD-xhtml-events-20010607/Overview.html
defines an XML format that could be extended to describe events in an
extensible fashion, converting them to the internal interface on
arrival.


> 
> > 4) Which legacy input drivers and device types do we want to support?
> > 	Details:
> >
> > 5) How do device settings (mouse acceleration) get set as devices are
> > added, replaced, and when switching users (Virtual Terminals)?
> > 	Possible strategies:

Dunno.  Not clear that one will actually need this, though I know we
need to be able to assign devices to X, or to other programs on other
VT's independently.  I'm inclined to mostly ignore this sharing of the
same devices across different VT's unless/until it is shown there is
real demand for it motivated by multiple realistic use cases.

> >
> > 6) [Add your own here]
> 
> 6) /dev/input/mice allows multiple mice to control the core pointer, how would 
> one achieve that same functionality (when so desired by the user) when using 
> evdev?

This should be left to the X Input extension; if it doesn't/can't do the
"right thing", we should fix it (it's been about a year since I last
reread XInput, so I don't remember).

			- Regards,
				- Jim