Re: input device support in xserver

Keith Packard wrote:

> 
> Around 12 o'clock on Feb 14, Warren Turkal wrote:
> 
>>    HAL<->mouse reader/dbus sender<->dbus<-> dbus
>>    receiver<->xserver<->xapp
> 
> That's a lot of context switches for mouse events, which will introduce
> significant additional latency into a system which is already slow enough.
> It concerns me.

HAL is built on dbus, we may be able to take out the specific mouse reader
app. Not to mention, I plan on an evdev driver first because of the
limitations in HAL's support of input devices in kernel 2.6.

> Oh, one extra twist here though -- the Composite mechanism doesn't (yet)
> provide any way to let an external agent manipulate the translation from
> physical motion to both hierarchy and logical position, we may want to
> figure out how this works at the same time, as one option would be to
> actually use this mechanism and pass the translated events to the server
> via dbus.  I don't know.

I guess I don't see how this ties to the mouse.

>>    1. how to notify apps of input device changes
> 
> That seems pretty straightforward; RandR sends a single "hey, something
> changed" event and leaves most of the complicated information to a
> separate request/reply.

I haven't done much investigation here.

>>    2. how to retain backward compatibility while moving forward
>>       gracefully
> 
> To some extent, it is impossible to be perfectly compatible and still gain
> the ability to remove devices (adding seems pretty easy).  Applications
> are going to break, let's focus on making things right before we try to
> kludge them so that the huge set of existing Xinput using applications can
> work in all situations without trouble.

I am willing to go with this strategy.

wt
-- 
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org