Creating a Calendar in Linux

Today I found a great program called "pcal". It can create good looking postscript calendars. Most importantly, it can mark holidays in the postscript output if a 'date file' (normally named .calendar) is provided to it.

I created a holiday list in my .calendar file as follows (the * after the dates indicate a holiday):

8/1/09*         "Muharram"
23/1/09*        "Netaji's Birthday"
26/1/09*        "Republic Day"
31/1/09*        "Saraswati Puja"
10/3/09*        "Fateh-Duaz-Duham"
....

and then used pcal as follows to generate a nice single a4 page calendar for 2009:

pcal -P a4 -o cal2009.ps -E -f .calendar -g holiday -w 2009

Here,
'-P a4' generates output for A4 sheet,
'-o cal2009.ps' names the output file,
'-E' lets pcal know that my "date file" has dates in European format,
'-f .calendar' tells pcal the name of my "date file",
'-g holidays' tells pcal to use a particular color (in my case the default grey) for holidays,
'-w' tells pcal to create a whole year calendar (i.e. a full year on a single page).

Setting "SHMConfig" to "true" for synclient to work in recent Linux distros

Situation:
==========

1. You use a synaptics touchpad on your laptop/netbook.

2. You use a recent Linux distro (like Fedora 10) that comes with a
blank /etc/X11/xorg.conf.

3. You don't like the way your distro has configured your touchpad by
default. For example, you would like to get a middle click by
tapping the upper right corner of the touchpad.

Solution:
=========

To change the synaptics touchpad options at runtime (i.e. while the X
Server is running), you need to use the command line program
"synclient" (or graphical programs like gsynaptics, etc.).

I prefer the command line "synclient" because it allows me to tweak a
lot of things that gsynaptics does not allow me to.

For example, to get a middle click by tapping the upper right corner
of your touchpad, run synclient with the following option:

synclient TapButton2=2 RTCornerButton=2

Read the synclient manual page for more details. Do a 'synclient -l'
to get the current user settings.

In Ubuntu 8.10, synclient is provided by the package
xserver-xorg-input-synaptics.

In Fedora 10, synclient is provided by the package
xorg-x11-drv-synaptics.

But to get synclient working, you need to have the option "SHMConfig"
set as "true" in your options to Xorg. This was earlier done by adding
the line:

Option "SHMConfig" "on"

in your /etc/X11/xorg.conf file in the Synaptics InputDevice section.
Now that this file is being deprecated, you need to find out how you
can provide this option to Xorg. If you are on Fedora 10 like me
(maybe this is also the case in Ubuntu 8.10, Fedora 9, etc.), you can
put this option in a hal configuration file in /etc/hal/fdi/policy/

Using root privileges, create a file named say, synaptics.fdi, in
/etc/hal/fdi/policy/ using your favorite editor, and put the following
there:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<match key="info.product" contains="Synaptics TouchPad">
<merge key="input.x11_options.SHMConfig" type="string">true</merge>
</match>
</match>
</device>
</deviceinfo>

Next, restart by using the command (as root):

/etc/init.d/haldaemon restart

(The above command is for Fedora users. Use hal instead of haldaemon
if you are on Ubuntu)

Next, restart X Server using the command:

killall -HUP Xorg

Once X Server restarts, you should be able to use synclient without
any problems.

For more information regarding Synaptics Touchpad configuration
and configuring other devices under Xorg, see
http://wiki.ubuntu.com/X/Config/Input

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).

I have been using XMonad as my primary window manager for a few weeks now. No problems whatsoever. But today, I felt like playing with Netbeans a little. That's when I discovered that Java applications don't seem to be able to draw their windows on the screen (except the splash screens) when under XMonad. I have seen that under GNOME/Metacity, the same application works fine. So, I googled for a bit and found this: http://www.haskell.org/pipermail/xmonad/2007-June/001078.html

It seems that the problem appears only with apps using the swing toolkit. But the solution is simply to set an environment variable:
--------------------------------------------
export AWT_TOOLKIT=MToolkit
--------------------------------------------

Thats all that was required to solve the problem.