From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Wed, 29 Jul 1998 13:42:22 +1000

Re: kgicon, etc [I don't have any scsi device!]

Rodolphe writes:

>  I'm glad I generated some programming enthousiasm with the kgicon target.
>  Personnally, I've a few criticisms concerning the hmm... approach. [1]

In our defence :-), kgicon is still more "proof of concept" than a fully
nutted-out system.  I wouldn't even call it "alpha", more like
pre-pre-pre-Alpha :).

>  Would it be possible to have the "make install" kgicon target test and
>  possibly build the /dev/fbX and /dev/fbXcurrent device files and special
>  symlink. Just to save a few minutes for the unaware... :-)

Good idea.

>  I'd like also the "insert" script to call ../util/con2fbmap if possible,
>  for the ones not having a "." in their root PATH (possibly due to a
>  PhD in computer security, or maybe even to a debian distribution :-)).

Maybe better is to install con2fbmap (and fbset) into /usr/local/sbin.

>  Concerning the dali driver adaptation, I have one question. Initially,
>  my kgicon.o module refused stubbornly to insmod due to the fact that
>  he could not "io_claim_region" its vga_io region
>  (see chipset/Cirrus/546x.c).
>  I insisted and wildly #if 0 the region claim (even though I perfectly
>  knew that my wise driver was perfectly right in not wanting to use
>  things that he did not own). It seems that the kgicon driver was able
>  to run like that. Do you think I broke something due to this quick hack ?
>  What is the right thing to do wrt that ?

IIRC it's a known problem (since the kernel's driver will already have
claimed the vga space).  The #if 0 is alright in the short term, I'm not
sure what exactly should be done in the long term...

>  Finally, I'm happy. I got something on the screen out of my 546x driver!!
>  :-)))
>  It was even readable. But, well, not easily. I got a graphical console
>  I think (it seems a little different from the usual one, and very slow).
>  But the start of each scanline was nearly in the middle of the screen.
>                                         Therefore I had something like
>  that on the screen...

I've had that happen inserting my ET6000 driver, and my feeling is that
the memory/stack trashing that causes lynx to Oops is also causing this.
It may even be a "thing not initialized properly" problem, I don't know.

>  I never had a problem setting a 640x400 graphic mode previously with
>  the dali kgi. So: is there a problem with the mode timings requested by
>  fb-kgi.c ? Is this due to my hack with the VGA IO regions ?
>  [Hmm, while re-reading: I use a VESA driver for the monitor: is it the
>  origin of the problem... I'm gonna check.]
 
Try the monosync driver.

>  Finally, I tried con2fbmap 1 0 to go back to the normal VGA, but this
>  failed miserably. Is it the right command ?

That command puts the consoles back on framebuffer 0, but what it
*doesn't* do is tell the kgicon driver to reset the mode back into text
mode (which vgafb assumes).  I guess "rmmod kgicon" (after doing
con2fbmap) should reset the mode (since "insmod" set it). I'll do some
experimenting later...

>  Thank you in advance for any help.

No worries.  It's good to have someone testing this stuff.

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/