Re: [linrad] VESA

[Joe Fitzgerald <jfitzgerald@xxxxxxxxxxxx>]

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