[Xorg] XINPUT driver, hot-plugging, etc

Keith Packard keithp at keithp.com
Wed May 26 15:51:06 PDT 2004


Around 18 o'clock on May 26, Joe Krahn wrote:

Hey, thanks a lot for looking into how to fix xinput.

> However, it probably would be good to have a standard way to notify X of
> lost/gained devices.

I suggest we add an event for this which the X server may send.  The event 
could just notify the client that "something" had changed and let the 
client re-query for the available devices; I don't think this is 
performance sensitive, and I worry that clients would have trouble dealing 
with inconsistencies between the ListInputDevices and event mechanisms.

> The single biggest problem I see with XINPUT is a badly designed
> XChangeDeviceControl(). It could be OK in the current form IF the
> controlType argument is changed to an Atom, and some general
> purpose DeviceControl structures added.

We might as well just add a new request that passes in the desired data; 
leave the existing request alone.  We've shied from changing the 
interpretation of existing requests in the past.

> Also, I have a possible view of network devices as having
> a "driver module" which, instead of connecting to a device,
> connects to an X-server that actually manages the device.
> This keeps from having to create a new net protocol. But,
> would the X Server protocol be efficient, and could one
> run micro-servers which do nothing but run a device?

I think this is a good architecture to try, at least, and it sure would be 
easy.  I can't think how it would be 'less efficient' this way; device 
events are latency limited, not bandwidth, so any inefficiencies in X 
encoding won't matter much (not that X is really inefficient).

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040526/4408cf74/attachment.pgp>


More information about the xorg mailing list