input device support in xserver
Warren Turkal
wt@midsouth.rr.com
Sun, 15 Feb 2004 10:12:59 -0600
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