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

[Jon Smirl]

On 7/27/05, Jim Gettys <Jim.Gettys at hp.com> wrote:
> 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.

I would much rather see multiple users handled by multiple servers.
The security implications of multiple users in the same server is very
complex.

> 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.

I don't know much about DBUS. Do the input devices have to exist on
it? Shouldn't they be exclusively owned by their driver? The driver
would open the /dev nodes directly. I am planning on making a PAM
script to assign ownership of these devices to the logged in user.

> 
> 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.

Vojtech said to tell him if there are more odd devices that need evdev
support. He is getting really fast at doing it.

> 
> 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.

Note that I am working at eliminating VTs. The current VTs system only
works single user. I would like to see it replaced with a user space
system where each user runs their own copy of the Xserver and user
space console program. This was the focus of my Kernel Summit talk.

> 
> > >
> > > 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
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
Jon Smirl
jonsmirl at gmail.com