Xref: utzoo comp.sys.sequent:893 comp.windows.x:35303 gnu.emacs.help:1740 Newsgroups: comp.sys.sequent,comp.windows.x,gnu.emacs.help Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!cs.washington.edu!pauld From: pauld@cs.washington.edu (Paul Barton-Davis) Subject: odd behaviour of X under DYNIX 3.0.12/DECstation Ultrix 4.1 Message-ID: <1991Apr15.205329.19296@beaver.cs.washington.edu> Originator: pauld@stowe.cs.washington.edu Sender: news@beaver.cs.washington.edu (USENET News System) Reply-To: pauld@cs.washington.edu (Paul Barton-Davis) Organization: Computer Science & Engineering, U. of Washington, Seattle Date: Mon, 15 Apr 91 20:53:29 GMT We have been seeing some odd behaviour from X clients on a 20 processor sequent running DYNIX 3.0.12 (although the server is on a monochrome DECstation 3100). The most easily described manifestation has been window updating errors, both in an xterm and in an emacs X window. If a full screen (16"+) window is used in fashion that should make it scroll a complete page or more (e.g press RET twice for more, or do a couple of C-v's for emacs), odd things will *often* happen. In the xterm, the screen will freeze for a while, and then wakeup, apparently to continue as normal. In the emacs window, the window is never be redisplayed (it locks solid) although it appears that emacs will continue to accept keyboard input (you can save the file, exit etc, and a dribble file will show that the keys were indeed received). In addition, emacs will not update its window when a resize takes place, at least not until an input event occurs. We also seem to have a problem with the X cut buffer being used by emacs as a DYNIX client - this behaviour does not show up when the client is on another (non-DYNIX) host. Has anyone seen this behaviour, or got any ideas on their cause ? thankyou -- Paul Barton-Davis UW Computer Science Lab ``to shatter tradition makes us feel free''