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

[Jim Gettys]

On Wed, 2005-07-27 at 15:19 -0400, Jon Smirl wrote:

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

You don't get close collaboration without pretty intimate relationships:
e.g. cut and paste has to work to be useful, and people need to share
real-estate without problems.  Eamon Walsh's work gives us a good place
to start, and it is needed for the MLS case.

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

No, DBUS is a RPC sort of protocol; it is a good way to talk to the
server, passing pretty arbitrary information, rather than rolling our
own or using some kludge on top of X.

It is also already used heavily in the modern open source desktops,
particularly Gnome.


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

In that case, lets plan on evdev only.  It looked pretty good when I
last looked at it (just before it became clear we had to set up the
X.org Foundation and I started spending/wasting all my time on politics
(though it looks like it hasn't been a waste).

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

Sure; in that case, the X server would have to remember the settings and
save/restore on VT switch.

				- Jim