> 
> Just tested kgi 19991017 snapshot on a fresh 2.2.10 kernel. All I
> could test was a textmode IBM VGA driver. Everything is rocksteady!

Thank you for testing. Well, there are some known bugs, but all in all
it's quite useable.
 
> A few 'bugs' that are not in the documentation:
> 
> - keyboard in svgalib programs does not work (probably because of the
>   RAW mode it operates in)

Mhmm... X operates in in RAW mode too... Could perhaps investiage 
this further? I don't have a chance to test svgalib (unsupported
chipsets).
 
> - when killing an svgalib program and switching consoles, almost
>   simultaneously, the screen goes black; it could be restored by
>   switching to x11 and back

Does this occur with a standard-kernel too? If not, it is a KGI bug,
if so, it is a feature. Showing that the emulation is able to produce
the same bugs.

> - alt-f? work in X11 too, where one would
>   expect them to be ctrl-alt-f?; this is probably hard to fix -

Yes and no. We just have to deny console requests if the keyboard 
device is in graphics/raw mode. A fix I would like to suggest is
to use CTRL-ALT-F? for console switching too.

> When/how will I be able to use libggi on kgi again? 

When the drivers are operational again. The Permedia2 driver works
quite reasonably, at least setting modes and exporting the
framebuffers. However, there is still some work to be done so that
it can take over a running board safely.

> Is there some place I can hack on a graphic mode for ibm vga? 

Yes.

1)      The fixed clock driver needs to be ported.
2)      The following drivers need to be written:

        chipset/IBM/VGA-meta.c
        chipset/IBM/VGA-bind.c

        ramdac/IBM/VGA.h
        ramdac/IBM/VGA-meta.c
        ramdac/IBM/VGA-bind.c

> (the source tree is, even after reading the docs over and over 
> and over again, very hard to understand..) I couldn't make out 
> if there was graphic support for ibm vga _at all_.

No there isn't. 

The concept behind the 'difficult' layout is actually simple, but not
yet documented. For each piece of hardware, there is a 'driver'. Each
driver consists of a register definition (.h), a 'meta-language' part 
(-meta.h) that implements the features of that piece of hardware
(e.g. how to set a video mode, what modes are possible, mode checking, ...)
and a 'binding part' that implements the hardware detection and access
stuff.

So, you would have to write a driver for the VGA, just to support graphics
modes (for text modes, just fall back to the VGA-text driver, as
the PERMEDIA driver does).

There is virtually no documentation, but also not yet a fully working
driver to document. Sorry, but getting the driver running is #1 priority
at the moment.

> All in all, it's gotten a lot more usable! Great work.
> 
> -- 
> Tijs van Bakel, <[EMAIL PROTECTED]>


                        Steffen

----------------- e-mail: [EMAIL PROTECTED] -----------------

Reply via email to