[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