[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linrad] VESA
- Subject: Re: [linrad] VESA
- From: Joe Fitzgerald <jfitzgerald@xxxxxxxxxxxxxxxx
- Date: Fri, 16 Apr 2004 10:32:47 -0400
I have been asking about regarding the -rmap VM problem on
www.experts-exchange.com ... a neat place to ask questions
See
http://www.experts-exchange.com/Programming/Programming_Platforms/Linux_Programming/Q_20952531.html
-Joe KM1P aka GSIJoe
"Sunnycoder" writes:
>If enabling this feature provide you some command or API, you can try
running that command and check the return value ... >If you can
elaborate a bit on this feature I can try to find out the details ...
>Also if this feature appears in kernel configuration options in make
xconfig, then there will be a corresponding variable in >arch/<your
arch>/config.in file and a corresponding header C file (I cant recollect
the name!!)... the names are pretty >descriptive so you will have no
difficulty in detecting the variable ...
>If it is configurable option let me know and I will try to search the
name of the header file too !!
.
Leif Åsbrink wrote:
Hi All,
The VESA driver of svgalib-1.4.3 is very slow because
Linrad writes pixels in the order order of increasing
frequency or time (the order in which the data points
are stored). This means that the VESA driver will have
to remap it's memory each time the vertical separation
between two pixels is too large (not very large)
Linrad-01.17 and earlier versions do not work well with
the VESA driver of svgalib-1.4.3. Overrun errors occur
when spectra change rapidly causing the need to move
many pixels. It has been possible to avoid these
problems by make the window sizes modest or by averaging
over many transforms so the pixels do not move so fast.
Linrad-01.18 works well with the svgalib-1.4.3 VESA
driver on reasonably fast computers - but not for the
oscilloscope functions.
I have installed svgalib-1.9.18 today. I needed assistance
from Matan Ziv-Av, head of svgalib.org because it does not
install automatically under Red Hat 9. The difference in
speed of the graphics is most remarkable. The VESA driver
"VESA driver, 65536KB VBE3" of svgalib-1.9.18 runs about
300 times faster than the 1.4.3 driver. Oscilloscopes run
faster on the screen than one can see (I will have to add
a trigger function some day...)
Redrawing the timf2 oscilloscope at 100 Hz (9 tracks, half
the screen width) requires about 15 % of the CPU power
of my PentiumIV 2.7GHz with the new driver. The time to
redraw it once with the old driver was about half a
second (useless).
The problem with installing svgalib-1.9.18 is related to
a feature called -rmap VM which is included in Red Hat
distributions. (It is a feature that makes the handling of
virtual memory more efficient.)
If there is anyone on this list who knows how one can find
out if the -rmap VM feature is enabled in the kernel for the
svgalib Makefile to know, Matan Ziv-Av would be grateful for
some help so he can make the next svgalib easier to install.
---------- (from Matan) -----------
The problem is that RH kernel includes a feature (rmap VM),
which is hard (at least, for me) to find. To compile
the module anyway, make sure you have the latest version
(1.9.18) and edit the file kernel26compat.h, changing line 10, so that
it is a copy of line 22 ( so that io_remap_page_range() sees 5
arguments). There might be similar issue with minor versus MINOR, which
requires similar changes near the end of the file.
.
.
.
Maybe you can help me here - all that is needed here is a
gcc pre-processor trick that will find out if the rmap VM is used.
---------------------------
I had to use Makefile.alt to compile svgalib_helper.
73
Leif / SM5BSZ
LINRADDARNIL