home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 3: Developer Tools / Linux Cubed Series 3 - Developer Tools.iso / utils / console / svgatext.3 / svgatext / SVGATextMode-1.3 / doc / screen-resizing.note < prev    next >
Encoding:
Text File  |  1995-04-30  |  5.7 KB  |  140 lines
  1. This file documents the possible problems and pitfalls you could encounter
  2. when trying to RESIZE the screen. 
  3.  
  4.  
  5. Kernel compatibility
  6. --------------------
  7.  
  8. SVGATextMode needs two features from the Linux kernel that are not available
  9. in all commomnly used kernel versions. 
  10.  
  11. The VT_RESIZE system call (actually an 'ioctl') has been introduced into the
  12. kernel only since version 1.1.54 (released mid-october 1994). Since this
  13. funtion is absolutely crucial when the screen needs to be resized,
  14. SVGATextMode cannot properly resize the screen without it. 
  15.  
  16. That is why it checks the kernel version before trying to resize the screen
  17. (if you select a mode that is different form the one that was used before).
  18. And if the kernel version is not "new" enough, it will refuse to continue.
  19.  
  20. There is no other simple solution to this problem than to either use only
  21. non-resizing modes, or to update your kernel to one that's a bit more
  22. recent.
  23.  
  24.  
  25. "Out of memory" problems
  26. ------------------------
  27.  
  28. There is also a (small) problem with SVGATextMode, when it uses the
  29. VT_RESIZE system call to do what its name suggests: resize the screen.
  30. If you are really low on memory, it could bomb out telling you:
  31.  
  32.      VT_RESIZE: out of memory
  33.  
  34. The explanation for this was sent to me by Alessandro Rubini
  35. (rubini@ipvvis.unipv.it):
  36.  
  37.      "When the kernel executes kmalloc() with GFP_KERNEL priority,
  38.      it must either suceed or fail. Did you notice that you've
  39.      always 80kB free memory? This is what the kernel keeps free
  40.      in order to do its own kmalloc()s. When resizing the consoles,
  41.      it first allocates the new screen memory, and the releases the
  42.      old one. So, if I switch to 132x60, i need 15840 bytes for
  43.      each existing vc (i.e. 16k, since kmalloc goes by powers of two().
  44.      If I have 8 open consoles (8 gettys), I need 128kB, which I
  45.      usually don't have unless I shrink_buffers(). The kernel can't
  46.      shrink_buffers() while kmalloc()ing, so it fails.
  47.      You could try to malloc() 1meg, writing it all and then free() it.
  48.      malloc() does shrink_buffers(), so you should end up with
  49.      enough free memory, unless a compilation is running and swaps pages
  50.      in before you ioctl(VT_RESIZE). It is important to write in the
  51.      memory you malloc() since Linux doesn't give you pages unless
  52.      you fault them in :-)"
  53.  
  54. Or in other words: the kernel needs REAL RAM for the new screen memory.
  55. Since it is a kernel function, it cannot use "virtual" memory. Your
  56. "virtual" terminals would become a bit _too_ virtual: they'd be on disk
  57. instead of on your monitor...
  58.  
  59. The suggestion above has been implemented (and re-implemented), with the
  60. result described above: much less memory problems, but still some.
  61.  
  62. It seems that the memory that is temporarily being allocated and then
  63. released is NOT always released IMMEDIATELY, so the kernel cannot get
  64. enough. And fails with the same error message.
  65.  
  66. If the VT_RESIZE call fails because of a lack of memory, SVGATextMode will
  67. revert to another little trick: it will first resize the screen to a 1x1
  68. size (1 character per VT!). This will probably never fail, since that
  69. requires only 2 BYTES per VT. But this frees all the memory the old screens
  70. consumed, and thus increases the chance of success for a new attempt at
  71. resizing the screen back the the desired size.
  72.  
  73. There is one downside to this last method. During the resizing to "stamp"
  74. format (one letter), all the screen memory is thrown away, including any
  75. text on them (except the leftmost character...)! Returning the screen to the
  76. new size will get you all blank screens. Not a pretty sight. 
  77.  
  78. Since SVGATextMode will then resize the TTY's, which sends a SIGWINCH to all
  79. applications running in them, most applications will react to this by
  80. redrawing their screen. But those who don't support SIGWINCH will NOT do
  81. that, and leave the screen blank. 
  82.  
  83. You have been warned!
  84.  
  85.  
  86. What to tell the applications that depend on the screen size?
  87. -------------------------------------------------------------
  88.  
  89. This is a bit of a mess.
  90.  
  91.  
  92. First: for applications that were started AFTER the resize:
  93. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  94.  
  95. Some applications use the tty setting to find out what size the screen is
  96. (as from "stty -a"). 
  97.  
  98. Some use the environment variables TERM, LINES and COLUMNS to get the screen
  99. size.
  100.  
  101. Some use the termcap file together with the TERM setting (e.g. if
  102. TERM=con80x30 then the program will look for a 'con80x30' entry in the
  103. /etc/termcap file for more information on the console's size and
  104. capabilities). 
  105.  
  106. Some use the terminfo database (which is a complete mystery to me).
  107.  
  108. Some badly written programs use nothing at all, and assume a certain screen
  109. size (especially things ported from DOS). These cannot be helped...
  110.  
  111.  
  112. The tty settings are normally automatically set by the resizing code in
  113. SVGATextMode. 
  114.  
  115. The TERM, LINES and COLUMNS environment variables are NOT changed, so you
  116. will have to do that yourself (e.g. in the "ResetProg).
  117.  
  118. This also means that programs using /etc/termcap will contu=inue to use the
  119. old settings, and may cause problems. Set the TERM variable for each
  120. terminal affected by the resizing.
  121.  
  122. Second: for applications that were already running at the time of the resize
  123. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  124.  
  125. Those are a real problem.
  126.  
  127. Many programs respond to a signal called "SIGWINCH" by re-reading the screen
  128. size parameters from the tty settings, and adapting their screen
  129. accordingly. These are the lucky ones. They will continue to look good.
  130.  
  131. examples: joe, less (more), elvis (vi)
  132.  
  133. But some don't. And you will probably have to restart them if you want them
  134. to use the new settings. The ResetProg is probably the ideal place for that.
  135.  
  136. examples: selection, gpm
  137.  
  138.  
  139.  
  140.