Newsgroups: comp.windows.x
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!xzaphod!michael
From: michael@xzaphod.uucp (Michael R. Miller)
Subject: Re: How to simulate mouse events from a data tablet
Message-ID: <1991Jun04.235308.21266@xzaphod.uucp>
Summary: Use the X Extension mechanism (a little long)
Reply-To: michael@xzaphod.UUCP (Michael R. Miller)
Organization: XZaphod in Rockville, MD
References: <1991Jun3.142241.14494@engage.pko.dec.com>
Date: Tue, 04 Jun 1991 23:53:08 GMT

In article <1991Jun3.142241.14494@engage.pko.dec.com> davis@3d.enet.dec.com (Peter Davis) writes:
>
>In article <1991May31.163832.22933@auto-trol.com>, marbru@auto-trol.com (Martin Brunecky) writes...
>>In article <1991May30.191703.11099@engage.pko.dec.com> davis@3d.enet.dec.com (Peter Davis) writes:
>	.
>	.
>	.
>> 
>>    Which means you have to properly simulate all enter/leave events. No
>>    thanx, I am giving up on that one -).
>>
>
>I think what's really needed here are XWarpButton and XWarpKey functions.
>XWarpPointer only does half the job.  There's really no reason why you should be
>able to warp the pointer position, but not be able to control the other input
>device values as well.

What is needed is to modify the server.  The server was designed with a decent
extension mechanism.  Extensions are treated as (almost) first class citizens.
Why not use the tool specifically designed to accomodate this situation?

The problem with trying to do OUTSIDE the server what should be done INSIDE
is the duplication of all that very good code to handle generation and
delivery of events.  Also you are missing that wealth of information buried
inside the server.

The XInput extensions were created to address this problem.  While not a
complete solution, it'll probably fulfill most needs.  One area I found as
"missing" was concurrency of use.  I had a need to be able to accept input
from a digitizing tablet, a touchscreen and a mouse as well as the keyboard
without any application changing the active pointing device.  This would
allow the user to simultaneously use the touchscreen and the mouse (Etch-a-
sketch time again) without any application intervening.  It took a little
effort to do this but the solution of modifying the server is the only
practical solution to your problem.

Someone will say: "But we don't have the source for the X server."  Please
recognize that MIT expected this to be source code available to the users.
The fact that you obtained the compiled version from some vendor of X that
doesn't offer the source code makes your job, perhaps, impossible to solve.
Any other solution will be inadequate for anything but a tightly controlled
X application environment.

Fortunately the X source tree ports to many environments fairly easily
these days.  Writing a DDX, especially for a device that is well designed
for X, is not terribly difficult (yeah, it takes some effort but so do
most things).  A competent C programmer should be able to do a DDX for
a board in a reasonable amount of time.  It'd take a much less than a
year to get the X11R4 server itself into robust shape for one good
programmer -- including your extensions (speaking from personal experience).
Fortunately the task is easily split into pieces so a team can do it.

Yes this is more expensive than buying a onesy or twosy from your
friendly OS/X11 vendor.  But if you've got 100+ machines to outfit, the
price of all this software work suddenly looks much better.

Michael R. Miller
uunet!xzaphod!michael