Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!nntpd.lkg.dec.com!engage!3d.enet.dec.com!davis
From: davis@3d.enet.dec.com (Peter Davis)
Newsgroups: comp.windows.x
Subject: Re: How to simulate mouse events from a data tablet
Message-ID: <1991Jun3.141727.14374@engage.pko.dec.com>
Date: 3 Jun 91 14:13:34 GMT
Sender: newsdaemon@engage.pko.dec.com (USENET News Daemon)
Distribution: usa
Organization: Digital Equipment Corporation
Lines: 27


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:
>>
>>>    Can you elaborate on why you have to XGrabPointer ? (I don't, and have
>>>    no problems I can see - so far).
>>
>>XWarpPointer generates it's own motion events.  However, the key/button mask
>>in those events is that of the "real" pointing device, rather than the
>>"fake" device you're simulating.  So, to get the events to have the correct
>>key/button mask, I think you have to grab the pointer, move it, and then
>>explicitly send events to the affected window(s).
> 
>    Which means you have to properly simulate all enter/leave events. No
>    thanx, I am giving up on that one -).
>

It's worse than that.  It seems that grabbing the pointer causes it's own
events, at least according to xev.  When I try it, I get all kinds of
EnterNotify, LeaveNotify, FocusIn, FocusOut, and KeymapNotify events that seem
to be all tied to grabbing the pointer.

It's beginning to look like you have to modify the server, or use an input
extension to accomplish this correctly.  It's too bad.  You can almost do it
from the application level, which sure would be nice.

-pd