SENGER@LAX.WISC.EDU (01/10/91)
I apologize if this has been discussed before. I just noticed that xev under 10.2 does not display the event information for the buttonpress until the buttonrelease occurs (i.e. press the mouse button and nothing happens, release and you get both buttonpress and buttonrelease information). Experimenting with a small program I find that the program receives the event at the expected time but I/O seems to be held up until the buttonrelease and subsequent print occurs. Any explanation? - steve senger@lax.wisc.edu
dpg@citi.umich.edu (David Gorgen) (01/11/91)
In article <21010915450698@lax.wisc.edu> SENGER@LAX.WISC.EDU writes: > I apologize if this has been discussed before. > I just noticed that xev under 10.2 does not display the event information > for the buttonpress until the buttonrelease occurs (i.e. press the mouse > button and nothing happens, release and you get both buttonpress and > buttonrelease information). Experimenting with a small program I find that > the program receives the event at the expected time but I/O seems to be held > up until the buttonrelease and subsequent print occurs. Any explanation? > > - steve > senger@lax.wisc.edu I assume you are using the X server in share mode, and running xev and your program from a DM pad. If you try running them from an xterm, you should see immediate output of the ButtonPress report -- I certainly see this in the case of xev. Your question is not a dumb one at all; you have discovered a subtle aspect of the Apollo share-mode X server. Here is the explanation. According to the X11 protocol, pressing of a pointer button must activate a grab on the pointer device, which lasts until all buttons are released. If no passive grab can be found to be activated, the server will activate a default kind of pointer grab, for which the grabbing client is the one which received the ButtonPress. Grabbing the pointer has many effects; one is to send all pointer events to the grabbing client, regardless of where the pointer roams. This is the reason for the default grab behavior: so that the client which got the ButtonPress will always also get the ButtonRelease, and no other client will get the ButtonRelease unexpectedly. Another effect of a pointer grab is that the cursor pattern is set to a fixed pattern regardless of where you move the pointer. You will note with xev that you can press the button, then move the mouse all over the screen (including into DM territory in the case of the share-mode server), and the same cursor pattern will continue to be displayed, until you let go of the button. This is equally true of all correct X servers. The unintuitive behavior of the share-mode server you describe arises from this cursor behavior. Apollo cursors are drawn with software, and although the DM/GPR cursor is drawn by the kernel, the X cursor is drawn by the X server (because the kernel cursor drawing code is not capable of drawing the 2-color X cursor). In order to be able to draw the X cursor over territory controlled by the DM or a GPR program, the share- mode server must hold the display device acquired for as long as the pointer grab lasts. Otherwise, the cursor drawing and the DM or GPR graphics operations might corrupt each other. As a result, although the program running in the DM pad issues its output, the DM is unable to gain control of the display device in order to show it. When the pointer button is released, the grab is released and the server releases the display; at that point, the DM can catch up. However, output generated in an xterm is displayed through the X server, and since the X server is already holding the display, it has no trouble displaying it. Ideally, the X cursor drawing would be delegated to the kernel, in which case the existing cursor interlocks used by the DM and GPR programs would solve this problem and the X server could be changed to stop holding the display while pointer grabs are in effect. However, I know of no plans to fix this. -- Dave Gorgen / GTD-East (formerly Apollo Computer), Hewlett-Packard Company located at: University of Michigan, CITI dpg@citi.umich.edu (Center for Information Technology Integration) 313-747-4075