[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: [Xorg] XINPUT driver, hot-plugging, etc
From:       Keith Packard <keithp () keithp ! com>
Date:       2004-05-26 22:51:06
Message-ID: E1BT7Eo-0004nu-00 () evo ! keithp ! com
[Download RAW message or body]


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



[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]