> > To verify that your fb driver works right, you can do something like "cat
> Did that /dev/fb0 is "up".
Good.
> Hmm. When I changed GGI_DISPLAY to 'fbdev', under X,
Oh - you don't use a conventional X server when running under fbdev. Doing
so will cause the fbdev driver and the X server to compete about the
hardware and this can cause very weird effects up to machine locks.
If you want to run an X server on top of an fbdev installation you either
use fbdev or XGGI.
> the screen goes black and looks very rudely console-like.
This is one of the possible effects of accessing the hardware from two
different driver sets. Don't do this.
> I guess this driver does not understand graphics-mode, so that it also
> cooperates with a mouse pointer.
A mouse pointer in the sense of a hardware sprite is not supported by LibGGI
currently. However this can be hacked quickly for a given hardware, if you
need the functionality. I do have higher level code to deal with sprites and
stuff.
> Is it there, where the KGI comes into play??
KGI is an alternate driver model. Don't play with the "real" KGI from
Steffen Seeger, unless you want to dive into writing hardware drivers and do
real lowlevel stuff. For now, please stick to either standard kernel
provided fbdev drivers or KGIcon drivers (which are built from the "kgi"
subdirectory of the degas LibGGI tree).
KGI is a pretty much ordinary fbdev driver, except that is has an extension
set of commands that allow for acceleration etc.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
