Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!mintaka!spdcc!dirtydog.ima.isc.com!ima.isc.com!eli
From: eli@ima.isc.com (Elias Israel)
Newsgroups: comp.windows.x
Subject: Re: How to simulate mouse events from a data tablet
Message-ID: <1991Jun05.154305.4813@ima.isc.com>
Date: 5 Jun 91 15:43:05 GMT
References: <1991Jun5.140807.13727@engage.pko.dec.com>
Sender: usenet@ima.isc.com (news)
Reply-To: eli@ima.isc.com
Organization: Interactive Systems, Cambridge, MA 02138
Lines: 81

In article <1991Jun5.140807.13727@engage.pko.dec.com>,
davis@3d.enet.dec.com (Peter Davis) writes:
|> Yes, modifying the server (and the O/S kernel/device drivers) is one
|> approach.
|> However, it has several drawbacks:

Hacking the server is really the only approach that's going to do the
right thing with all of the events, even if you were of a mind to try
and duplicate event propagation code in a client (yuk). The only way
that you're really going to get the right behaviour out of the system is
to add your tablet to the server, using the input extension already in
the MIT code.

This approach isn't without it's problems. Getting extension events to
Xt-based clients is -- err --  tricky, as others have already noted.

|>    o	It requires server level expertise to develop and maintain.

True, but as I said, it's the only way to get the job done, really.

|>    o	It must be constantly re-implemented and re-tested against O/S
|> 	and server upgrades.

My guess would be that the input extension will not change very much in
the future. I doubt that it would take a whole engineer's time to keep
up with that extension, or with changes to the extension interface in
the server. (Mind you, this is a *guess*. I don't claim to know what Bob
S. and Keith P. are thinking)

As for changes to the O/S, you'd have to manage those even if you didn't
make a server change. Either way, when your O/S changes, you'll have to
hack drivers.

|>    o	It's not very attractive to an unsophisticated customer.  ("Here,
|> 	just save your old sources, load this tape, then re-build your O/S
|> 	kernel, and then re-build your X server and you're all set.")

Installing a new driver in the kernel is something that our end-users do
all the time. There's no reason why they can't handle it if they have
the right tools. (And the tools I'm talking about aren't even
particularly user-friendly). Having end-users hack the server is a
problem, I'll admit. But if you can send them a fresh binary instead of
telling them to re-build their server, you might be able to get away
with it. Depends on your business model, I guess.

|>    o	It makes it difficult to quickly test out new input devices.

I'm not sure that it would be significantly easier the other way.
Testing devices is difficult. It always has been, whether you're talking
about kernel drivers or X input.

|> Perhaps the "correct" solution would be to have X provide a facility for
|> down-loading server extensions.  This would solve some problems today, such
|> as how to applications which depend on certain extensions run on servers
|> which don't have them.  It would also make it easy to implement an extension
|> once, and have it be insulated from future O/S or server changes.

This isn't possible, as far as I can see. Every time the staff at MIT
has written a new extension, they've found a new area of the server code
that needs to be expanded or modularized, or sometimes just changed to
give extension developers a new hook. It's hard to imagine how you can
completely insulate extensions from changes in the server, or how you
could download an extension, except in the trivial sense of dynamically
loading an object file into a running server. (And even that requires
some trickery.) Extensions are rather intimately tied up in the rest of
the server code; much more so that it might seem at first.

On the other hand, I don't think that the burden of keeping up with the
server changes is likely to be very large in the future. (Putting aside
for a moment the multi-threaded server experiment, the fate of which is
still undecided as far as I know.)

Ordinarily, all of the signs point away from using extensions when
you're trying to solve an X problem. In this case, however, extensions
are the only game in town.

Elias Israel		   | "Justice, n. A commodity which in more or
Interactive Systems Corp.  | less adulterated condition the State sells
Boston, MA		   | to the citizen as a reward for his allegiance,
eli@ima.isc.com  	   | taxes, and personal service."
eli@village.boston.ma.us   |     -- Ambrose Bierce, _The Devil's Dictionary_