From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 16 Apr 1999 22:48:20 +0200

Re: kgicon troubles - mode switching (and more)

Joseph Carter wrote:
> 
> Seems that anything that asks for a particular mode be set does not run
> at the moment with my kgicon module.  If it doesn't ask for a mode the
> thing runs great.  ggi-warp will demonstrate the error I'm getting:
> 
> knghtbrd@icarus2:~$ ggi-warp
> display-fbdev: FBIOPUT_VSCREENINFO: Invalid argument
> LibGGI: Failed to set mode: 320x200.[P8/8]
> Error switching to 320x200 8 bpp mode.
> Under X, try using -d depth_of_your_screen.
> 
> Monitor setting (nifty display eh?):
> 
> /dev/fb0:
> Optiquest
> V95
> GM_ALL
> FL_MON_POWERSAVE
> 1600x1280
> 362x267
> VGA_COLOR
> SYNC_SEPARATE|SYNC_ON_GREEN|SYNC_COMPOSITE|SYNC_STANDBY|SYNC_SUSPEND|SYNC_VESA_DPMS
> 0-200000000
> 30000-95000
> 50-160

You'll need to add SYNC_MULTISYNC to the SYNC_* flags. If you don't you
can only used pre-defined modes (which you don't appear to have any).
SYNC_MULTISYNC will enable the automatic timing calculation (note that
you can have both pre-defined modes and automatic timing calculation
for unlisted modes).

> And would someone please be so kind as to tell me where there is
> documentation on the blasted kgicon cursor?!  This blinky white block has
> gotten at best QUITE annoying.  =>  Make it a blinky underline or make it
> a solid block, the blinky block is driving me bats!  That and I remember
> the solid yellow from ages past and kinda miss it.  =>
> 
> And while I'm on about things unrelated to the problem I'm requesting
> answers for, has someone considered [ab]using the gpm source to create a
> fbcon/kgicon friendly mouse thingy (technical term?) that will keep track
> of the cursor seperately on each console and resolution?  Perhaps since
> we're doing this whole framebuffer thing here we could consider making a
> graphical mouse pointer on consoles which are framebuffers?
> 
> Is there a good/sane/reliable way to figure out from a script if there is
> a framebuffer device being used or if for example svgatextmode can be
> run?

Not in a generic way such that it would be useful to distribute it.

> How about distinguishing between kgicon and matroxfb to figure out
> if XF86_SVGA should be run or XGGI is needed? 

However to achieve the above you can just check whether /proc/fb
contains "KGI".


> BTW, amazingly svgalib4ggi almost worked with the current zgv installed
> on my system.  The keyboard was completely screwed and I still had to
> magic sysrq R my way to another console to kill I think if I can fix the
> mode switching problem it may actually be possible (shocked horror) to
> get zgv to actually display an image!  Which means it may be possible to
> figure out why the keyboard isn't working right at some point maybe!
> (okay maybe I'm hoping for too much..  svgalib is evil and zgv moreso,
> still if it can be gotten to work it would certainly be impressive
> considering the level of evil involved in these two beasts..)

The SVGAlib wrapper was mainly written with the Quake variants in
mind, as there is no source available for them. For zgv and other
opensource programs it's better to port them to LibGGI.

However, as many people seems to mention zgv I will have a look
at it to see if it's possible to run it with the wrapper.
Where can I find the latest source for zgv?

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se