[Xorg] XInput Hotplug Additions

[Kristian Høgsberg]

Jim Gettys wrote:

...

>>>This device might be local, or remote.
>>>
>>>2) Via some protocol over this socket (might be dbus, might be 
>>>some other protocol, as simple as the current name/value pairs
>>>used in the current configuration file nightmare), the X server 
>>>is told to set up the new input device).
>>
>>D-BUS doesn't let you pass file descriptors, so I guess that's out.
> 
> 
> No, I don't think it is an issue here.
> 
> I'm thinking of the case to allow the design to deal with new
> device types.
> 
> If you look at the porting document for XInput, it looks as though
> the X server can be educated about pretty arbitrary input devices, with
> pretty arbitrary combinations of keys, buttons, locators, displays,
> etc...
> 
> It is an incremental process.
> 
> You say: Here's a new device.
> It has some buttons,
> it has some keys,
> it has N axes,
> and so on....
> 
> to allow pretty arbitrary devices to be described.  I'm actually
> reasonably impressed at the ideas behind the design.
> 
> I don't understand how to do this in a one step process.

You would just specify all that in one request, e.g.:

	Device: <file descriptor here>
	Driver: xmlevent
	Buttons: 7
	Keys: A B C D E F
	
I don't see why the server and the hotplug daemon need to discuss back 
and forth about this, if it can be done with just one request.  I guess 
I'm just trying to keeps things as simple as possible.

If the server can not add the device with the given options it reports 
this back, of course, but this should be exceptional, e.g. out of memory.

>>>3) If so, after initialization, 
>>>the socket associated with the device gets sent to
>>>the X server (via send()), along with some information to allow
>>>the X server to filter the byte stream (or do the right IOCTL's),
>>>via some interface, for delivery of events after the device
>>>has been initialised.
>>>
>>>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.
>>
>>Wouldn't it be better to do 2 and 3 in one go, i.e. send a request 
>>saying "setup a new input device, use this filter, use this fd".  That 
>>avoids state in the protocol and makes the whole setup simpler.
> 
> 
> To set up a device, we may have to do a whole sequence of
> operations.  E.g.
> 
> a) load the correct device driver
> b) set it into a known sane state
> 
> It isn't clear to me that we want both/either of those in
> the module loaded into the X server.
> 
> So we can let hotplug get things into a state that
> X can use, and, rather than X having to reopen the device,
> and thereby potentially have to reinitialize it, pass the
> file descriptor to the X server when it is ready to go.

Again, I'd like to keep this as simple as possible, and as I said above, 
I don't see anything that prevents us from sending this information as 
one request.  When the server receives the requests it works its way 
through the options in the request and sets up the driver accordingly, 
finally adding the file descriptor and enabling the device.  If 
something goes wrong, it unrolls the steps taken so far and reports an 
error back to the hotplug daemon. Otherwise it sends a confirmation that 
the device was successfully added.

...

>>So we should try to figure out what kind of interface the server should 
>>expose on this local socket and what kind of protocol to use.  I can't 
>>see that we would need anything more than add device and remove device 
>>requests.  The add device request passes the fd, the name of the filter 
>>to use, and possibly a set of options for that filter.
> 
> It is the setup of new devices where the interface has to be reasonably
> rich; or you can't support arbitrary devices.

As I mentioned on IRC, I'm not crazy about exposing such a rich API over 
a custom IPC mechanism.  For one, it's a lot of work, and I'm not sure 
how it's better than letting the driver do this work.

Kristian

Btw., you've mentioned an XML-based event protocol a couple of times; do 
you have a link for this work?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: evdev.c
Type: text/x-csrc
Size: 21521 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040805/4a25c523/attachment.c>