Re: [linrad] VESA

[Joe Fitzgerald <jfitzgerald@xxxxxxxxxxxxxxxx]

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