[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

.Linux fiddling with svgalib...long..

Hello, All!

I took some time off from the VHF contest this afternoon to play a bit with Linux, and I thought what I did might be of some help to others (I hope).

First of all, I have had a minor glitch in the operation of my ATI Radeon 32 MB DDR AGP 4X videocard in that when in Linrad, if I pulled one displlay box over another, or tried to push a box off of the screen, instead of resisting this movement, Linrad would lock up the computer and only a mechanical power-off and reboot would get things working again.

I was using RedHat Linux 7.2 with the 2.4.7-10 kernel, and svgalib 1.4.3. I was using the modified r128 driver, as the man who maintains svgalib indicates that the stock r128 driver for 1.4.3 SHOULD NOT be used.

Switching on VESA in the /etc/vga/svgalib.config file produced NO change in the behaviour.

I could not upgrade to svgalib-1.9.17 as it would not compile, even with the suggestions and tricks that Conrad G0RUZ used.

So here is what I did:

1. I used the RedHat 'up2date' utility to install the 2.4.18-19.7.x kernel and kernel source. I don't know that I needed the source for now, but wanted to have it for future potential use.

2. Because I boot from a floppy, I did
mkbootdisk --device /dev/fd0 2.14.18-19.7.x to put the new kernel on my boot floppy.
After rebooting from the floppy, I was running the new kernel

3. At the command line, I typed (Thank You Kohjin!):
ln -s /sbin/ldconfig /bin/ldconfig

4. I again tried to install svgalib-1.9.17, just slightly altering Leif's prescriptions on his URL:

5. The 'make install' ended in the .../svgalib_helper directory with an Error (2) message. At that point, per Conrad's suggestion, I went to this directory
( cd /usr/local/src/svgalib-1.9.17/kernel/svgallib_helper )
and typed 'insmod svgalib_helper.o'

6. After doing this, I set the mouse type to 'PS2' and set my horizontal and vertical scan rates in /etc/vga/svgalib.config .

7. Now Linrad would run, but it seemed to have only 16 colors, and as a result the displays were not pretty, and the waterfall was nearly useless in terms of detecting weak signals.

8. So I removed the "#" in front of the VESA statement in /etc/vga/svgalib.config so that the videocard is using the VESA drivers . With this I have again a reasonable-looking Linrad screen (I use screen mode 1024 x 768, #12). The screen is not quite as pretty as when I was running in R128 mode, but it is OK, and now Linrad and the computer will not lock up when I push boxes and things where they should not go. The program will not let me do these bad things; it fights back and keeps the boxes where they should be. So that annoying problem is fixed.

9. But I did not like having to type 'insmod svgalib_helper.o' before running linrad after booting the computer, and I have many different versions of linrad on the machine that are always changing, so writing a script for each one would be a pain as I'd always be needing to write new scripts.

10. So I made a textfile called 'svgalibhelper' and put it in the /etc/rc.d/init.d/ directory. The files is a script that runs at bootup and does the insmod thing. the file contains the text:
#! /bin/bash
cd /usr/local/src/svgalib-1.9.17/kernel/svgallib_helper
insmod svgalib_helper.o
Note that you need to set the permissions on this file so that users can execute it or it will fail on bootup.

Then I typed at the command line:
ln -s /etc/rc.d/init.d/svgalibhelper /etc/rc.d/rc3.d/S57svgalibhelper
ln -s /etc/rc.d/init.d/svgalibhelper /etc/rc.d/rc2.d/S57svgalibhelper
ln -s /etc/rc.d/init.d/svgalibhelper /etc/rc.d/rc5.d/S57svgalibhelper
for the run modes I usually use. This may not be necessary, but I feel safer doing it.

Having done this, this script runs everytime the computer boots or one goes to runlevel 2,3 or 5 with the init command. So you never have to manually type 'insmod...' You will see it with the other listed startup scripts when you boot up, and if you did everything right it will have a nice green [OK] after it as it flashes by.

11. Having upgraded the kernel, I of course had to reinstall OSS because OSS complains when it finds a new kernel, and refuses to run. So I took the opportunity to download the latest version of OSS too and then reinstalled the new version of OSS. This must be done before step 7, above. I didn't put it there as it broke the flow of what I was describing to do so.

12. Everything is working fine now (no lockups) EXCEPT that before I was able to enter and exit Linrad with no problems, as often as I wanted to, by typing 'cntl-alt-F7' to leave Linrad and 'cntl-alt-F*' to reenter it. So I could go and do lots of other things in Linux while Linrad was running and then return to Linrad with no problems. Now the screen is corrupted having coarse white and purple text and texture over the screen when I reenter Linrad from XWindows. Those portions of the screen that are periodically rewritten by Linrad clear up as they are rewritten, so something else has overwritten screen memory during the period XWindows is being displayed. This is a pain, but it is better than having the computer lock up when I play with display boxes in Linrad. Of course, an "X" and a "B" bring things back to where they should be by rewriting the whole screen.

I hope that is helpful to someone. I also hope I didn't make any typos ;)



Roger Rehr
2 Merrymount Road
Reading, PA 19609