[Xgl/Xegl] Input Devices

[Waldo Bastian]

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:

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

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

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

> 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:
>
> 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?

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050727/2d31fd3f/attachment.pgp>