> I have come to the conclusion  that I have a VESA 1.2 BIOS (I do have a S3Virge). 

This might well be. At the time Virges were popular, 1.2 was the usual VESA
version.

> I downloaded the file and tried to do the patch but am having no luck.
> I am posting it here for others to look at that may have a better
> understanding of how the patching process works. I read the man page but
> I am still not really sure as to how this is done. It appears that there
> are 3 files patched by this file??? 

Yeah - I'll tell you a little about how diff files look like below on the
example you posted. Might help some people.


> Is this correct and can someone tell me if I am on a wild goose chase 
> or not.  (:

It might work. The problem with V1.2 is, that it cannot set up linerly mapped
framebuffers, though the S3 chips are capable of using them.

But now for the diff files explanation:

Diff-files (patches) contain the difference between two versions of text
files, such as C source code. They are used to distribute small changes to
larger pieces of software for update purposes or to change some part of the
behaviour.

There are multiple formats that have evolved over time, but today almost
anyone uses so called "context diffs", which have the advantage to be
relatively easy to read for humans, to be resistant to small changes in
other areas of the code and to be reversible.

They have the following general structure:

> --- linux/arch/i386/boot/video.S.orig Sun Oct 25 13:46:40 1998
> +++ linux/arch/i386/boot/video.S      Sat Feb 13 18:01:49 1999

Such lines are used to start a section of a diff that deals with a new file.
Thus multiple source files can be patched with a single diff.

The --- line gives the filename and date of the original file from which the
change started out, the +++ line gives the same data on the new file, that
already contains the changes. As when developing you usually back up the old
file, and then modify the original, the second filename is used when
patching.

> @@ -554,13 +554,22 @@

@@ starts a section that specifies changes for a given range of lines
within one file. There can be multiple such sections per file, to be able to
efficiently transfer multiple changes in one file that are far apart.

The two range specifiers contain starting line number and number of lines
for the old and the new version of the file. The differences themselves are
then below that header. In this case, the header means, that at line number
544 the next 13 lines in the old file are changed to 22 lines in the new
one. The second starting line number can be different from the first one,
because there may have been another @@-section before, which will skew the
whole file ...

>       cmp     al,#0x09
>       jz      setvesa         ! this is a text mode
>  
Lines that start with "  " are unchanged from the original. There are always
3 unchanged lines at the start and end of a context diff, to allow for
synchronizing with the source in case of a slightly modified source.

> +#ifdef CONFIG_FB_S3CARD
> +!
> +! removed the check for linear frame buffer as
> +! we're going to try and turn it on ourselves
> +!
> +#else

Lines starting with "+ " are added to the original source, lines starting
with "- " are remove (doesn't happen here).

> --- linux/drivers/video/Config.in.orig        Fri Jan 22 21:56:07 1999
> +++ linux/drivers/video/Config.in     Sat Feb 13 18:09:51 1999

Here the next file gets patched.

> --- linux/drivers/video/vesafb.c.orig Fri Nov 27 20:24:31 1998
> +++ linux/drivers/video/vesafb.c      Sat Feb 13 18:05:20 1999

Here you have an example of the line number skewing:

> @@ -21,6 +21,7 @@

This one adds a line to the original, and

>  #include <linux/selection.h>
>  #include <linux/ioport.h>
>  #include <linux/init.h>
> +#include <linux/pci.h>
>  #include <linux/config.h>
>  
>  #include <asm/io.h>
> @@ -32,8 +33,12 @@

This the second linenumber is skewed by one against the original.

>  #include <video/fbcon-cfb24.h>
>  #include <video/fbcon-cfb32.h>
>  
> -#define dac_reg      (0x3c8)
> -#define dac_val      (0x3c9)
> +#define dac_reg              (0x3c8)
> +#define dac_val              (0x3c9)

Here we have a not-so-nice case, where reformatting stuff caused a patch to
be generated that has no real effect. Two lines are removed and then added
again with different formatting.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]>        =

Reply via email to