home *** CD-ROM | disk | FTP | other *** search
/ Amiga GigaPD 3 / Amiga_GigaPD_v3_3of3.iso / netbsd / docs / mailinglist-archive / 1993-12 / text0382.txt < prev    next >
Encoding:
Text File  |  1993-06-25  |  3.4 KB  |  70 lines
  1. >Maybe these keys could be caught by X and it could close kbd? dunno it
  2. >will need to know when to reopen them too I guess.  I was connsidering
  3. >writing a CX like daemon when I started messing with ite.c, not there yet.
  4.  
  5. Okay, I don't know how ite/grf/view/kbd/mouse are configured right now,
  6. but, I was just thinking about this problem and thought maybe I should
  7. toss some ideas out for arguments' sake.
  8.  
  9. What if, in addition to /dev/viewXX, there were /dev/mouseXX and
  10. /dev/kbdXX devices (where XX are numbers).  From an application
  11. standpoint, you open exclusive inputs and outputs (with matched
  12. numbers).  The kernel must then provide a user focus for each of these
  13. devices.  The focused view would be visible on screen, the focused
  14. keyboard would get keyboard information (make sure focus changes only
  15. happen when there are no keys pressed??), and the focused mouse would
  16. get mouse information (again, make sure no mouse buttons are pressed). 
  17.  
  18. It should be possible to change these focii in a configurable manner. 
  19. Some people will want Motif like changes where keyboard, mouse and view
  20. change together, others will want Intuition like changes, where keyboard
  21. and mouse change together, independantly from view.  I'm sure someone
  22. will want to be able to use their mouse on one view, type on the
  23. keyboard in another, and look at a third...
  24.  
  25. Things that really need to be thought about: what about multiple
  26. displays?  How about when the view focus changes, it affects only the
  27. display to which the view is associated, leaving whatever was last
  28. active on the other display.
  29.  
  30. Actual focus changes.  Perhaps a special keyboard device which can be
  31. programmed to trap only certain keys before they get sent through the
  32. /dev/kbdXX interface.  Then, user configurable keystrokes could be
  33. watched for by a daemon to change keyboard/mouse/view focii. 
  34.  
  35. >There are no sprites :^( Sprites didn't figure quickly into the RTG
  36. >system I had dreamt up.  I still have problems with RTG, let alone
  37. >trying to get a sprite into the system. :^)
  38.  
  39. Well, since at least one graphics device (cc) supports a hardware
  40. sprite, I think support for them should be included.  Since one graphics
  41. device that supports hardware sprites draws them using huge pixels
  42. (again, cc) it should be configurable.  I think it is part of a view to
  43. know whether a hardware cursor can be rendered or not, and to handle
  44. that rendering.  From an X server, it means if'ing out (or using
  45. pointers to functions or something) the cursor rendering code.
  46.  
  47. Another thing to think about is a DUALPF screen - provide a monochrome
  48. overlay akin to certain sun graphics boards.
  49.  
  50. >Use of the CPU is much faster than the blitter on all machines that
  51. >NetBSD currently (and probably hereforth) runs on.
  52.  
  53. Yes, but, by the same token, I'm sure on a fast enough machine I could
  54. write a PIO SCSI driver that is at least as fast as DMA.  The difference
  55. is PIO consumes many cycles from other things the machine could be
  56. doing, whereas DMA happens without much processor involvement.  Same
  57. with the blitter.  If I decide to turn OpaqueMove on in twm (once I get
  58. NetBSD and X installed and running...), I want the blitter to move the
  59. windows (if possible) not the CPU - that way everything else in the
  60. system can stay running. 
  61.  
  62. Just my thoughts.
  63.  
  64. >Chris.
  65.  
  66. Gregory Kritsch        | 3A Computer Engineering at UWaterloo   
  67. ggk@tirith.uucp        | "Life is a highway
  68. ...!xenitec!tirith!ggk    |  Life is a stinking highway!" -BNL
  69.  
  70.