This file documents what should be changed to this program in the future. 
It is mainly for "internal use only", so don't worry if it's completely rubbish.


1) Ideas and suggestions for enhancements
-----------------------------------------

- More "man" files for _all_ tools would be nice...

- when an error occurs in the middle of hardware programming, recovering
  from it would be nice instead of just bailing out, and leaving all
  registers in an undefined state (= a bad state) ...
  How to to this? 

  Maybe use the "save_regs" function from the XFREE code before doing
  anything, and perform a "restore_regs" afterwards. This is only realistic
  when using more of the XFREE code.

- Of course, MORE CHIPSETS!

- Should really consider moving SVGATextMode closer to the XFREE3.x code, so
  developing new chipset-support is faster. Also use their code for some
  things (chipset detection, clock selection, register programming
  macro's...).
  
  check out xfree86/vga256/vga/vgaHW.c: contains register programming stuff
  
  This would allow me to use CLKREG_SAVE and RESTORE, so when something goes
  wrong, I can always restore registers. Much safer...

- Clockprobe/grabmode: Try to find a way to check for interlacing WITHOUT
  using chipset-specific stuff.
  
  For this reason, the MClk setting ability is nor documented, nor promoted
  in the manuals. You have been warned...

- setVGAreg: add "REG" regset, so reg 0x3c3 can be read (et4000).
  This needs a generic syntax for index/data sets and for single registers!

  It must then also get VGA perms for _all_ regs asked for, avoiding
  addresses >0x400 (the system call doesn't work for >0x400), and give
  warning when non-standard address (or out of normal VGA range) is used.

- set80 MUST get a lot more robust before it will be useful to most people.
  The extended clock selection registers are the biggest problem. Maybe just
  programming ALL special clock selection registers for ALL chipsets that
  are tricky (ATI, ET4000, ...) would work. Wrong registers will (?) get
  ingnored ayway. 

- A new program: "Xclockprobe": probes for the ENTIRE clocks line (like X):
  do one clockprobe for the 25 (or 28 MHZ) clock, warn if 25 and/or 28 are
  not there (=non-VGA), do other clocks like X (or not?) Could thsi be
  combined with grabmode?

- Try to parse text mode label, and see if the X x Y values match the real
  ones, and give warning if not! (useful for people who don't understand the
  non-relationship between the label and the actual text mode size.)

- XFREE 3.1.2 clock chips (but watch out for the Cirrus and S3/Et4000 changes!)


2) Really wild or less useful ideas
-------------------------------------

- S3 supports "high speed text font writing". After finding out what it
  does, Try it. Maybe the Max clock limit of 70 MHz can be lifted up that
  way... (see also page 3-2 of the S3 805 data book)

- Measure the V-freq of the mode that was programmed in the chips, and
  compare it with the calculated one. If there's too much difference, do
  something nice (like restoring the old state)... (a "paranoia" switch ?)
  
- check out mkmf, mkmk!!

- Add "Et4000_newclocksel" option, which uses the clock selection method
  described in doc/README.ET4000.AltClockSelect. But then the user needs to
  input a different clocks line (with up to 96 clocks).
  
- But then we need a clocks line probe (like the one in XFree86)...

- Consider an X/Windows style "rgb.txt" and being able to say in TextConfig
  "Palette 0 navy blue" & "Palette 7 IvoryWhite". (K. Albanowski again ;-)

- Extend the monitor range checking to allow the user to ask for the "best
  fitting (refresh, font size, ...) "X*Y" mode for his setup. Maybe call the
  the "-b" option ("best"). (suggested by Mr Albanowski)
    
- Another obvious extension is full Monitor/Card blocks, like in XFree.
  3.1. (suggested by the same one...)

- A utility to test the monitor capabilities by sweeping through the freq
  ranges: first H, keeping V constant at 60 Hz (by decreasing H-size), then,
  using the H limits, test V!

  Dangerous... (?)

- In theory, H-timings CAN be given with PIXEL precision instead of 8-pixel,
  using the "pixel panning" registers for both screen and cursor.

- Allow the user to select color or monochrome mode from the config file.

- merge ClockProg and SVGATextMode ?

- grabmode/clockprobe: let them scan for config file, and if there is one,
  use device-dependent extensions.
  
  Of course, this breaks the entire "chipset-independance" idea behind the
  mode grabber. 

- try to create a better 32-high font, and maybe even some fonts between the
  16 and 32 pixel boundaries. Let someone else do this :-)

- sorting the default TextConfig per Hor refresh frequency instead of the
  hodgepodge it is now.

- see Ferraro pg 363: DES could be used to allow VGA more time to access
  font/char data. e.g. start using this when pixclock > (DEFAULT_MAXCLK - 10).

- overscan color definition?

- GPL? 

*** - for V2.0: maybe use svgalib interfaces for hardware instead of custom
***   routines. Could be compile-time switch?
*** 
  


3) BUGS and other "features" that should be improved.
-----------------------------------------------------

- grabmode: some 320x200 are _still_ detected as 640x400, or 640x200. And
  now, XFREE modes sometimes are detected as 512x768 instead of 1024x768...

- Try finding out why free() does not always immediately free up the memory.
  VT_RESIZE gets into trouble in that case! This is probably a problem
  caused by the really wild memory management used in Linux.

- VT_RESIZE problem: when a previous attempt via 1x1 failed, then the next
  user attempt at restoring the screen back from 1x1 to something a little
  more useful will not even TRY, since it believes the screen doesn't need
  to be resized (intelligent software "sucks pond slime"...).

  In fact, I need to re-think use of VT_RESIZE and the out-of-memory problem
  completely. It sucks (pond slime).
  
  Maybe we should check on the amount of free memory BEFORE doing the
  VT_RESIZE call (/proc/meminfo?)
  
  Maybe even wait until memory is there (with proper warning, as fron the
  NFS-server when it loses connection: "Not enough memory... waiting until
  we get some")

- LOTS of DOSEMU compatibility problems...:

  * ET4000W32p/ics5431: DOSEMU re-programs original values in clock regs! So
    when you switch back to linux console, your text mode clock is wrong.

  * Maybe even use ClockProg as in X to restore textmode clock when
    returning to text mode. This is especially useful for clockchip owners
    where clock is not restored in programmable clock regs)

- There's a big problem in the MClk setting code: sometimes this causes a
  complete system hang (that's why this option is not promoted or
  documented).

  This also seems like the way the 911 and 924 (etc) chips do 132-wide
  modes. Would this solve their problems, too?

- For some reason, ClockPrg is VERY flaky in X! On some et4000's, the SEQ
  regs cannot be programmed from the ClockProg...

- dependencies: if a file in XFREE/common_hw has changed, "make" doesn't
  re-make anything! Should we use a Makefile in that directory?

- grabmode should check for the natural (incrementing) order in the h1 h2 h3
  h4 and v1 v2 v3 v4 sequences. If not correct, warn the user that the
  results will probably be wrong.
               
- clear all chipset-specific H/V size extended regs (they are not used, and
  not even programmed in STM, so they could cause mayhem. They also reduce
  the chance for succes when trying to restore a broken textmode with STM).

- grabmode : interlacing still wrong

- interlace detection: maybe check vga address each V retrace (how?), if +-
  equal, non-interlace.

- Interlace detection: 
  if not golden ratio:
   * if active_v = 600/2 or 768/2 or 1024/2 (or 1200/2 ?) then probably interlaced
   * if not one of the above: probably hi/truecolor.

- make STM programs print out in which kernel they were compiled, next the
  the version number
  
- usage messages don't look so good in 80x25...

- See if DOSEMU can be compiled with SVGALIB support, so it can restore
  chipset regs for more chipsets/clockchips. This way they don't have to do
  it themselves (again).

- Find out if ALWAYS resetting the CLOCKDIV2 bit, even when the option isn't
  enabled, is a good thing to do. It would reduce the chance of weird
  behaviour... Especially Cirrus Logic needs testing on this.

- make default DacSpeed dependant on the font width: allow 9/8 DacSpeed for
  9-pixel wide fonts

----------------internal---stuff-------------

mail processed up to: 963





