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

[Joel Dice]

On Wed, 27 Jul 2005, Jim Gettys wrote:

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

Also, consider the possibility of "fast user switching" as featured in 
Apple's OS X, where each user has a persistent desktop session which they 
can switch to on a shared machine.  This could perhaps be implemented 
using multiple servers, but it might preclude interesting transition 
effects.

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