home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sgi / 18416 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  3.1 KB
  1. Path: sparky!uunet!olivea!sgigate!odin!sgihub!zola!zuni!anchor!olson
  2. From: olson@anchor.esd.sgi.com (Dave Olson)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Mouse Interrupts
  5. Message-ID: <ubatc1c@zuni.esd.sgi.com>
  6. Date: 1 Jan 93 18:43:35 GMT
  7. References: <AJ3U.93Jan1103135@larch.cs.virginia.edu>
  8. Sender: news@zuni.esd.sgi.com (Net News)
  9. Organization: Silicon Graphics, Inc.  Mountain View, CA
  10. Lines: 55
  11.  
  12. By the way, 'comp' is *not* a valid distribution.  If your news
  13. software inserted it automatically, you should get your news admin
  14. to update their software.  I've removed the Distribution header.
  15.  
  16. In <AJ3U.93Jan1103135@larch.cs.virginia.edu> aj3u@larch.cs.virginia.edu (Asim Jalis) writes:
  17. | 1. What mechanism does IRIX use to determine if a mouse button
  18. | has been pressed?  I assume it uses interrupts but I am not sure.
  19.  
  20. Yes, it is interrupt driven.  On all current machines, the mouse
  21. and keyboard use the same DUART chips as the regular serial ports,
  22. and the same low level driver.
  23.  
  24. | 2. How much time does it take between a mouse button being
  25. | pressed and a user program running in non-preemptable mode (i.e.
  26. | with a highest non-degrading priority) being informed about it if
  27. | it is using qtest() to constantly check the status of the event
  28. | queue.
  29.  
  30. The question is unanswerable as asked.  If you are on an MP machine,
  31. and dedicate a processor to your process, I think the guarantee is
  32. within 400 usecs.  On a single processor machine, the worst case
  33. will probably be a few milliseconds.  Typical times will probably
  34. be much less (on the single processor machine).  Note that mouse
  35. events got through the X server, so the answer also partly depends
  36. on how much memory you have, since if parts of the server (or your
  37. program, for that  matter) get paged out, you obviously increase
  38. the latency.
  39.  
  40. | 3. Is there another way to find out the status of the mouse, or
  41. | to set up some kind of a signal that would interrupt the program
  42. | if the mouse button is pressed, that is presumably faster than
  43. | using qtest()?  And there is such a way, then how much time does
  44. | it take between a mouse press and the program being informed
  45. | about it?
  46.  
  47. Well, you could just queue the mouse button, and then block with
  48. qread(); at least you won't be doing as much polling and eating
  49. up CPU time.  Other than that, no, their really isn't much you
  50. can do to reduce the time to you getting the event.
  51.  
  52. | 
  53. | 4. If the information required by questions (2) and (3) is
  54. | unknown then how can I determine it?  I have been thinking about
  55. | a possible software solution, but I have not been able to come up
  56. | with anything satisfactory.
  57.  
  58. Measure it.  Put an analyzer on the mouse port, and then have your
  59. program write a character to one of the serial ports when it gets the
  60. event, and use that as your second trigger.  Yes, that adds a few more
  61. variables, but you should be able to get a decent average, and 'worst
  62. case' value that way.
  63. --
  64. Let no one tell me that silence gives consent,  |   Dave Olson
  65. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  66.     Maria Isabel Barreno                        |   olson@sgi.com
  67.