All of lore.kernel.org
 help / color / mirror / Atom feed
From: Knut Petersen <Knut_Petersen@t-online.de>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: geodefb issues, possible patch
Date: Sat, 12 Nov 2005 08:37:29 +0100	[thread overview]
Message-ID: <43759BB9.70409@t-online.de> (raw)
In-Reply-To: <eb77d7060511110405i13b8bc8aw335147185398cd22@mail.gmail.com>


>i have a patch if someone is interested. the problem is that i dont
>know what else to do, as i cant debug (with printf's) the driver as i
>dont have a screen, how does a fb driver gets debugged? 
>
First of all, it´s a good idea to allow the driver to be compiled either 
as a
module or as a permanent part of the kernel. If it´s a module, it is really
helpfull if it can be unloaded / reloaded.  Allow your driver to be loaded
with vesafb or vesafb-tng compiled into the kernel, normally that should
be possible if you do not fail if you cannot get exclusive access to some
resources vesafb reserves. That way you might start with vesafb, load 
version
1 of your driver, map consoles to either one, do some testing, map all
consoles to vesafb, unload your module and load a new version. That helped
a lot in debugging cyblafb.

If you do loop for some conditions, always include a timeout.

Use printks, and have a look at the system log after a reboot.

Use a serial console or another computer connected via network.

Let the driver display some status information at a fixed location of
the screen.

First of all: write a userspace program that does a complete register dump.
Boot with vesafb and all vga=??? parameters supported by the bios and store
those register dump.  Include a register dump function in the driver and 
compare
the register values to those found for vesafb.

Don´t believe documentation that indexed registers end at index x if x is
less than the highest possible value. If bits of a value are stored in 
several
places (e.g. vga screen start address), don´t assume that the documentation
documents all high bits.

Get it right unaccelerated first.

cu,
 knut



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

      parent reply	other threads:[~2005-11-12  7:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-11 12:05 geodefb issues, possible patch Jorge Luis Zapata Muga
2005-11-11 13:25 ` David Vrabel
2005-11-12  1:30   ` Jorge Luis Zapata Muga
2005-11-14 13:52     ` David Vrabel
2005-11-15  2:23       ` Jorge Luis Zapata Muga
2005-11-12  7:37 ` Knut Petersen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43759BB9.70409@t-online.de \
    --to=knut_petersen@t-online.de \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.