Hi !
> >If the appropriate modes are not found, the LibGGI driver will not be able
> >to give timings to the card, which usually results in bad timings. You
> >should have gotten a warning about that at runtime.
> Yes, i translated my X modes useing modeline2fb into a /etc/fb.modes file to
> no avail.
Do you really have an X mode set up and working for 320x240 ?
Please test that mode with the X server. If that isn't it, it might be
something with not parsing additional hints correctly or similar.
BTW: Heretic has a -mode parameter that should change resolution, however it
doesn't seem to work right in my outdated copy.
> however when i first started i had no /etc/fb.modes file...
> where should i find the error message if something is wrong with
> /etc/fb.modes?
Wait ... oh - it's a debug-message:
/* Try to get the timing from the standard database */
if (get_timing(TIMINGFILE,&var)) {
GGIDPRINT_MODE("display-fbdev: cannot get timing from"
TIMINGFILGFILE". Just hoping it works.\n");
}
You can enable full debugging comments on LibGGI using GGI_DEBUG=255.
Running a program like GGI_DEBUG=255 ./program 2>logfile will provide us
with lots of useful debugging info, if something goes wrong.
> exactly :) anyone we should tell? the [EMAIL PROTECTED] list?
> (someone told me about that one today)
Yes, probably. Or maybe better the author of the fb driver in question.
It was the ATI Mach, IIRC - right ?
Looks like the current maintainer is:
* Copyright (C) 1998 Eddie C. Dost ([EMAIL PROTECTED])
However we can try to collect some extra debugging data first. Run the
GGI_DEBUG probe, and maybe we can narrow down the problem.
> >No. kgicon is an alternate driver model that is capable of producing
> >drivers
> >for various environments, including fbcon.
> >If you fbcon is working fine, there is no need to use kgicon.
>
> How does that differ from KGI?
Well - the basic idea we had, was to unify graphics driver development.
The KGI system is a general setup we use for driver development. The
resulting drivers can be linked to glue layers that vary between the
environment the driver will run in.
Up to now there are four such environments:
1. fbcon/kgicon. The driver will be linked with a glue-layer, that will make
it look like a standard fbcon driver. This is the preferred usage for now.
2. "real" KGI 0.0.9. This is a new design maintained by Steffen Seeger,
which requires heavy patching of the Linux console system to work. This is
in the flux, but stabilizing now. Moreover the drivers need to be changed
a bit to work with and take advantage of the advanced environment KGI
provides.
3. suidkgi. I haven't checked that for a long time, as it is IMHO a bad
hack, though it was useful to prove the concept of the abstract graphics
drivers. It will link the whole driver into a LibGGI target module which
is directly loaded and executed by the application. This requires root
priviledges for the application, of course.
4. Some other mysterious OS. I can't tell anything about it, but I can
assure you, that the KGI drivers for at least VGA, Permedia 2 and MediaGX
work fine, there.
> >You mean a /etc/fb.modes ?
> yes, i created it using the modeline2fb program. It seemed to have no
> effect.
And you created a mode for the resolution that failed to set ?
And the mode works fine when trying it with fbset ?
> cool! I've got access to some Diamond Stealth 2000/3000's, a Voodo banchee,
> a ATI Mach 64, a Trident TGUI9440-1, and some STB powergraph 64 (trio64V+)
> cards (all PCI). Would any of them do it and have a driver available?
I have to leave the answer to someone else here.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
