Hacked an old driver to work under new linux kernels

Yesterday, I had to purchase a "PCI to parallel port" multi-I/O card to get the Xilinx Parallel IV cable to work on the Dell machines in our Lab (these PCs did not come with a parallel port, only USBs).

The card was from EnterMultimedia based on WCH352 chip. I am currently on Ubuntu 8.10 with 2.6.27 kernel. But after connecting the card and rebooting, the card was not detected by Linux. Well, actually it did detect it, but as some serial device for which no driver was found, and I could not find any /dev/lp0 or /dev/parport0. So, I looked into the driver CD that came with it, and found a linux driver (I did not expect to find it though)!
Tried to install it, but it turned out to be trying to use lp.o and parport_pc.o modules, both for old 2.4 linux kernels. No wonder the modules were not found in my system (and would not load even if they were present). To make matters worse, the 'installer' (well, hardly an installer... seemed to me more like a program that acted as some kind of wrapper using lp and parport_pc kernel modules for their work) was a compiled binary file without any source code provided on the CD.

So, after some head scratching, I decided to open the binary file using vim, and searched for 'parport_pc.o' and 'lp.o'. Found it, and then replaced them with 'parport_pc.ko' and 'lp.ko' respectively. Tried to run the file again, and it promptly responded with a segmentation fault. I had definitely jumbled up the addresses of different instruction in the binary, which the linker had worked hard to setup.

Then I did two things. First, changed the binary file so that now, 'parport_pc.ko' became 'parprt_pc.ko' and 'lp.ko' became 'l.ko' so that their length became same as their original names in the binary. Second, made a copy of the corresponding modules in my system and renamed them to reflect the new names for the binary file to be able to load them. Then, I ran depmod (I don't think it was required though, but well, did not hurt anyway).

Now I ran the binary file again, and voila, new devices /dev/lp0, /dev/lp1, /dev/parport0 and /dev/parport1 (dunno how lp1 and parport1 appeared though) have now appeared in my system :-)

Compiled Metacity (from svn) to get drop shadows!

Yesterday I tried compiling metacity downloaded from subversion.

I read an article (from epologetics.org) containing some information on
compiling metacity from subversion. Following it, I first installed the
following packages on my Ubuntu 7.10 (Gutsy) system:
--------
sudo apt-get install gnome-common build-essential autoconf gnome-devel libtool
-------

Then, I tried to run:
-------
./autogen.sh
-------
which gave some errors about something like 'shift 370: can't shift that many'.
Then I tried reading the autogen.sh file and noted somewhere that I required
automake-1.10. My installed version was 1.9. So I installed 1.10 and tried again.

This time it progressed much further, but again bailed out while trying to run
aclocal-1.10. The error said something about '/usr/share/aclocal' being an invalid
option. I tried reading up on the aclocal manual page, and found that, to include
a directory of m4 files for aclocal, you need to use the -I option.
Another reading of autogen.sh showed that it was somehow calling gnome-autogen.sh.
Then I tried reading the relevant portion of gnome-autogen.sh where it was calling
aclocal-1.10. Turns out that it was calling aclocal as 'aclocal-1.10 /usr/share/aclocal'.
I tweaked this file a little so that it was now calling aclocal as
'aclocal-1.10 -I /usr/share/aclocal'. After that I again ran ./autogen.sh.
This time ran to completion... also invoking './configure' somehow, which also seemed
to run fine.

Now I ran 'make' and everything went smoothly. I was able to successfully compile
metacity from subversion on my system. Oh I forgot to mention, I used the enable
compositor option for configuring metacity, and now I get drop shadows in windows
and the gnome panel in metacity... cool :-)

By the way, I have the feeling that I would not have to do all these tweaking stuff
and everything would have gone smoothly if I had used gnome-common from
subversion (as was mentioned in one of the files I read) instead of the version
available from Ubuntu's gnome-common package.

Update: Just now (19th April, Saturday), I tried doing the same thing on a
different computer (this too, an Ubuntu Gutsy, but this one has access to the
internet and is regularly updated). Here, I did not need to put the '-I' option on the
aclocal line in gnome-autogen.sh file (as mentioned in my original post). In fact,
it gives me an error if I do so. But without that, the thing compiles just fine (with
automake 1.10 installed).