From: Knut Petersen <Knut_Petersen@t-online.de>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: xgdfalcon@gmail.com
Subject: Re: mode switching on intelfb and non-CRT displays
Date: Sun, 23 Oct 2005 09:05:33 +0200 [thread overview]
Message-ID: <435B363D.3030308@t-online.de> (raw)
In-Reply-To: <4354AD3A.3070504@gmail.com>
Hi Tony,
>>What would it take to get intelfb mode switching working with non-CRT
>>displays?
>>
>Documentation. Or you can try googling for vesafb-tng.
>
>
Something like that should be possible even without documentation from
vendor xyz.
0: google, read X sources, etc.
1: Extend a private version of vesafb and xyz-fb with a function
that dumps all known
hardware registers. Call it at the end of the xyz-fb_set_par()
routine and while loading
vesafb.
2. Boot several times (without loading X) and save a vesafb register
dump for every
valid vesa mode.
3. Compare the register dumps and try to be intelligent ;-) Most
probably you will
find that only a few registers differ. Some will change with
differnt color depths,
some will change with different vertical and horizontal resolutions.
Also a clock
divider needs to be discovered.
4. Verify your assumptions and release a mode switching xyz-fb driver.
It might also be a good idea to write a little dumpreg program for DOS
and/or Windows.
If there is e.g. a utility program for DOS that allows you to change the
refresh rate, it
should be quite easy to identify the clock divider registers.
ypan and ywrap scrolling does help a lot to increase speed. Try to
identify as many
bits of the crt start address value as possible by instrumenting vesafb.
Simply call your
register dump function at the end of vesafb_pan_display() for several
times and have a close
look at the bits changed during scrolling. Don´t start displaying those
register dumps immediately,
that way you obviously would lock your pc.
cu,
knut
PS and ONLY for the brave: Write a little DOS program that single steps
the BIOS, saves all
IO to the vga register range to a buffer and displays it after
completion of the mode switch.
If the BIOS tries to prevent single stepping in real mode, switch to
vm86. It´s even possible
(and easier to implement than a vm86 monitor) to use a memory manager
like qemm386 and
a few lines of assembly code to map a writable copy of the video bios
image at the place of
the original bios if necessary.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
prev parent reply other threads:[~2005-10-23 7:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-17 17:35 mode switching on intelfb and non-CRT displays Larry Latouf
2005-10-18 8:07 ` Antonino A. Daplas
2005-10-23 7:05 ` 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=435B363D.3030308@t-online.de \
--to=knut_petersen@t-online.de \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=xgdfalcon@gmail.com \
/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.