[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
.Linux fiddling with svgalib...long..
- Subject: .Linux fiddling with svgalib...long..
- From:w3sz@xxxxxxxxxxxxxxxx>
- Date: Sun, 19 Jan 2003 18:52:28 -0500
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:
http://ham.te.hik.se/homepage/sm5bsz/linuxdsp/install/svgainst.htm
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
and
ln -s /etc/rc.d/init.d/svgalibhelper /etc/rc.d/rc2.d/S57svgalibhelper
and
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 ;)
73,
Roger
W3SZ
--
Roger Rehr
W3SZ
2 Merrymount Road
Reading, PA 19609
http://www.qsl.net/w3sz
LINRADDARNIL