The gspca drivers are available from here, I was using a specific version dated 20071224 to work with a patch file I found - many thanks to redeye on the QuickCam team forums. If you use a different version of the drivers, you can just examine the patch file and insert the changes manually.

First, download the drivers and the patch

wget http://mxhaard.free.fr/spca50x/Download/gspcav1-20071224.tar.gz
wget http://forums.quickcamteam.net/attachment.php?aid=86 -O patch.tar.gz

Then extract and apply the patch:

tar -xvf gspcav1-20071224.tar.gz
tar -xvf patch.tar.gz
cd gspcav1-20071224
patch -p1 < ../quickcamE2500.diff

There’s a handy build script included with the drivers so just run that (requires root):

sudo ./gspca_build

This generates the file

gspca.ko

which we use to replace the old gspca module.
Check to see if the old module is loaded, you should see something like:

dave@baracus:~$ lsmod | grep gspca
gspca                 680656  0
videodev               29440  1 gspca
usbcore               146028  9 gspca,snd_usb_audio,snd_usb_lib,usb_storage,usbhid,libusual,ehci_hcd,ohci_hcd

We want to find out where it is, so do the following:

sudo rmmod gspca
sudo modprobe -v gspca

You should see something like:

insmod /lib/modules/2.6.24-20-generic/ubuntu/media/gspcav1/gspca.ko

That is the location of the file we’re looking for, so, replacing where appropriate with what was output for you above, type:

sudo rmmod gspca
sudo rm /lib/modules/2.6.24-20-generic/ubuntu/media/gspcav1/gspca.ko
sudo mv gspca.ko /lib/modules/2.6.24-20-generic/ubuntu/media/gspcav1/
sudo modprobe gspca

This should have loaded the new module in place of the old one. See if you have a video device:

dave@baracus:~$ ls /dev/video*
/dev/video0

You can try and run Skype now, and in fact, if you’re not using the camera for Skype, this may well be enough. But for the Skype users: see if you get any picture by testing in the video devices option menu (be warned, it can take a little while to show up there after skype loads, and a little while for the picture to show when you press the test button, so be patient). If anything show’s up at all that’s a plus.

Originally, I had a black image, so I assumed the camera wasn’t working, but I soon realised that the image was there, just very dark - shining a light on it showed this was the case. I tried fiddling around with gstfakevideo for a while to try and alter the output, but there was a much simpler solution. The gspca driver itself can take options, and an autoexposure setting was ruining my lighting. To fix this, edit the file /etc/modprobe.d/options, and add a line at the bottom:

options gspca gamma=1 autoexpo=0

The gamma=1 may not be necessary, but if it still appears too dark or too light for your taste you can change this parameter as you like. Finally, reload the module:

sudo rmmod gspca
sudo modprobe gspca

and try out skype again. Hopefully it works!

I ran into quite a lot of other problems while I was trying this out, so if you come across any errors, drop a comment below and I’ll try and get back to you asap.

UPDATE: I found a large problem when using the camera in Skype was that CPU usage would shoot up to 100%, causing things to freeze up and conversations to crash after a while. I had played around with gstfakevideo a bit when trying to get the camera to work originally, and it seems using this when the camera already ‘works’ means it uses up far less CPU. I haven’t had a chance to test it for a long period yet but it seems like it should do the trick. Here’s what I did:

First, download gstfakevideo using subversion (you may need to install the subversion package, sudo apt-get subversion probably does the trick, and then the command below will make a directory called gstfakevideo in your current location, so make sure it’s somewhere nice), then compile and install it:

svn checkout http://gstfakevideo.googlecode.com/svn/trunk/ gstfakevideo
cd gstfakevideo
make
sudo make install

gstfakevideo creates a new video stream using your webcam, which is formatted differently and skype seems to get along with it more. The only problem is, it outputs its stream to /dev/video0 which is where our webcam currently lives. So we have to move the webcam, but this is easy enough:

sudo mv /dev/video0 /dev/video1

(Actually, gstfakevideo seems to work for me with lower CPU without moving this - but try it moved first anyway). Watch out though, every time you reboot, your webcam will probably go to /dev/video0 by default, assuming you have no other video devices, so you will have to move stuff about to make a space in video0 each time. Now we see if it works:

gstfakevideo v4lsrc device=/dev/video1 ! ffmpegcolorspace

What this does is runs gstfakevideo, telling it that the source we’re using is a v4l source, and its from /dev/video1. The ffmpegcolorspace argument seems to be for making the stream YUV instead of RGB for some cameras so may not be necessary. It then launches skype, with hopefully the output below:

dave@baracus:~$ gstfakevideo v4lsrc device=/dev/video1 ! ffmpegcolorspace
gst.c create_pipeline (155): pipeline created
gst.c create_pipeline (159): pipeline linked

If you look in the skype video options now there will be no camera listed. You have to wait a while (it can take 30s or so), until you get some output, ending with something like:

gst.c shim_ioctl (201): request=803c7601 nr 1
gst.c shim_ioctl (208): VIDIOCGCAP
gst.c shim_ioctl (313): result=0 error=0 Success

Now a camera should show up in the video menu in skype, with a name like GStreamer fake video (/dev/video0). Try it out, and compare your CPU performance to before. Also try exiting skype, and moving your video source from /dev/video1 back to video0, and running gstfakevideo again, only with device=/dev/video0, and see if it works (and let me know your findings below!).

Finally if gstfakevideo works, we can clean it up so the command isn’t so long to type. The script should be stored in:

/usr/local/bin/gstfakevideo

(Can check this using):

dave@baracus:~$ whereis gstfakevideo
gstfakevideo: /usr/local/bin/gstfakevideo

So we edit this file (requires root):

sudo gedit /usr/local/bin/gstfakevideo

Now, find the line that looks like this:

export GST_PIPE="videotestsrc is-live=true ! video/x-raw-yuv,width=640,height=480,framerate=10/1 ! videoscale ! ffmpegcolorspace ! vertigotv ! ffmpegcolorspace"

and change it to (remember where you put your webcam source - if you moved it back to /dev/video0, change the device parameter accordingly):

export GST_PIPE="v4lsrc device=/dev/video1 ! ffmpegcolorspace"

and finally look a bit further down, and delete the line:

export GST_PIPE="$*"

Now Skype will launch with your faked video stream, just from the command gstfakevideo. Good luck! Let me know how you get on.

jsvi is an excellent javascript implementation of vi. I decided to try and integrate it into my TiddlyWiki, and the steps I took are shown below. To try out the final result, use the edit mode on my wiki.

Be warned: this is a bit of a dirty hack, and requires a few files external to the TiddlyWiki file, which makes TiddlyWiki a bit less portable. At some point it’d be nice if this was build as a TiddlyWiki plugin instead, but at the minute I’m not experienced enough with writing plugins for TW. There is also a slight bug which means you can’t scroll up while editing.

First of all, I installed the iFrameEditorPlugin from an old version of the VisualTW site. I don’t think VisualTW uses the plugin anymore, and has instead changed it’s wysiwig editors to using plugins rather than iFrames - a far superior solution, but one I didn’t have the time or ability for. The plugin alone is not quite enough though, and a few changes to it are required.

iFrameEditorPlugin loads an iFrame containing your editor, passes the editor the text from the body of the tiddler, you edit it, and then when you save the page, the plugin gets your changes and saves them to the tiddler. However, it expects you to use a custom field rather than the default text field, which is a slight problem in our case. The function getContent() is what actually performs this:

getContent=function(tiddler, field) {
    var t,f;
    t=store.getTiddler(tiddler);
    f = t ? t.fields[field] : "";
    f = f ? f : "";
    return f;
}

As you can see, it reads the field of the tiddler with t.fields[field]. To read the default text field instead, I added a new function to the plugin:

getContentText=function(tiddler) {
 var t,f;
 t=store.getTiddler(tiddler);
 f = t ? t.text : "";
 f = f ? f : "";
 return f;
}

Great. So that’s set up. There’s also another problem with the plugin - it was originally intended for use with wysiwig html style editors, but I enjoy editing my wiki content raw. Also, the content has to be passed in a URL to the editor, so strange characters in the URL will mess it up, so there were problem with escaping html entities and things like that. To get around this, I found a handy javascript function that converted html entities back to their original form, and added this to the top of the plugin (thanks to The JavaScript Source):

/* This script and many more are available free online at
The JavaScript Source!! http://javascript.internet.com
Created by: Ultimater | http://webdeveloper.com/forum/member.php?u=30185 */
function html_entity_decode(str) {
  var ta=document.createElement("textarea");
  ta.innerHTML=str.replace(/</g,"<").replace(/>/g,">");
  return ta.value;
}

Ok, now we actually have to use this function, so we edit the plugin a bit more. Look for the line that reads the data back from the iFrame:

if(f) fields[f] = e.contentWindow.getContent();

and change it to:

if(f) fields[f] = html_entity_decode(e.contentWindow.getContent());

The plugin is all ready to go now, so we have to make the actual external editor that’s gonna go in the iFrame, using jsvi. Download these three files, and put them in the same folder as your TiddlyWiki html file.

vi.js
vi.css
editor.html

The first two are the actual jsvi javascript file and it’s style sheet, the second is my own editor iFrame. Let’s have a look at the important lines of the editor.html file:

<script type="text/javascript" src="vi.js"></script>

This includes the jsvi javascript file.

<textarea style="width: 99%" name="theEditor" onfocus="editor(this);">
</textarea>

This builds the actual textarea that’s gonna be edited by jsvi. Ok, now the javascript “meat” of the page:

var oEditor = document.getElementsByName('theEditor')[0];
function getContent() {return oEditor.value;}
tiddlers=/[\\?&]tiddler=([^&#]*)/.exec(unescape(window.location.href));
fields=/[\\?&]field=([^&#]*)/.exec(unescape(window.location.href));
if (tiddlers&&fields) oEditor.value = parent.getContentText(tiddlers[1]);
oEditor.focus();

All that happens here is we write the getContent() function that the iFrameEditorPlugin calls to read your changes. The tiddlers line reads the URL to get which tiddler you’re editing, and the fields line does the same for the field (actually this isn’t even necessary with our getContentText() function). The last two lines read the tiddler’s content, so we can edit it, and set the focus to the textarea to launch jsvi automatically when the iFrame loads.

That’s everything setup now, so all we need to do is tell Tiddlywiki when we want to make our edits with the iFrameEditor instead of with it’s default text field. I made a plugin (based on code from VisualTW’s EasyEditPlugin - thanks a lot!). You can view the plugin here. Hopefully it should add a ‘vi’ button next to the edit button on each tiddler. If no button appears, add ‘jsvi’ to the first line of the ViewTemplate tiddler to look like this:

<div class='toolbar' macro='toolbar closeTiddler closeOthers +editTiddler jsvi > fields syncing ....

To make jsvi the default, remove the + from in front of editTiddler and put it in front of jsvi.

Now when you press the vi button, you should be presented with a rather gorgeous vi interface! One note, when you’re done editing a tiddler with jsvi, you must save it using the usual vi write command, :w, or press the “Save and Close” button. Otherwise the textarea does not get updated, and the iFrameEditorPlugin cannot read your changes. Also beware editing config shadow tiddlers with jsvi, as the line “macro=stuff” in some of the tooldbars etc. is interpreted by jsvi as it’s own command and it can end up destroying certain things.

Update: I found a small problem with focusing using this in Firefox (didn’t test in other platforms) - after editing a post I was unable to select other fields and items in the window. This was fixed by changing one line in the vi.js file, line 3588, which needs to be uncommented (the comment line before even refers to a bug in Firefox, possibly in an older version?) to look like this:

document.body.removeChild(backing);

Now it should work perfectly, apart from a few kinks: being able to edit the tiddler title the first time jsvi launches. Save and close vi, and it’s editable again, and still editable when you relaunch jsvi by clicking on the text area. If you cant get focus back on jsvi, right click it.

Hope you enjoy this as much as I do, and hopefully at some point soon when I have a bit more free time, I’ll have it in plugin format so it’s all incorporated into TW. Any problems, leave a comment and I’ll try and get back to you.

This uses LatexRender, my simple TiddlyWiki macro, LatexRenderPlugin, and a custom script I created for the purpose, render.php, which renders LaTeX fed to it as an argument. You’ll need imagemagick enabled on your server.

First you need access to a server with the ability to run LatexRender. Download the latexrender.zip, and extract the “otherPHP” directory. Copy the class.latexrender.php, and latex.php files to a folder on your webserver. Set up the directories in each file accordingly. For example, I have my wiki set up like so:

webroot/physiwiki/latexrender:
class.latexrender.php
latex.php

and two subdirectories (which the webserver needs write access to, chmod 777):

webroot/physiwiki/latexrender/pictures
webroot/physiwiki/latexrender/tmp

So in class.latexrender.php, I have:

var $_picture_path = "/absolue/path/to/physiwiki/latexrender/pictures";
var $_picture_path_httpd = "/physiwiki/latexrender/pictures";
var $_tmp_dir = "/absolute/path/to/physiwiki/latexrender/tmp";

Also, make sure the paths to latex, dvips, convert, identify are setup correctly on the lines below. You can also make changes to the other settings in this file if you want including image format. The default is gif, I changed it to png.

Now latex.php by default generates the html to show an image, like:

<img src="blah">

We dont want this. So some changes to latex.php are required. First adjust the paths in latex.php:

$latexrender_path = "/absolute/path/to/physiwiki/latexrender";
$latexrender_path_http = ".";

The ‘.’ is used as latex.php resides in the same directory as class.latexrender.php.
Next, scroll right to the bottom of the file, and you can comment out/delete the last few lines, and change the return value to $url instead of $text as below:

    $url = $latex->getFormulaURL($latex_formula);

    /*
    $alt_latex_formula = htmlentities($latex_formula, ENT_QUOTES);
    $alt_latex_formula = ...
    $alt_latex_formula = ..

        if ($url != false) {
            $text = substr_replace($text, "<img src='".$url."' title='".$alt_latex_formula."' alt='".$alt_latex_formula."' align=absmiddle>",$pos,strlen($tex_matches[0][$i]));
        } else {
            $text = substr_replace($text, "[Unparseable or potentially dangerous latex formula. Error $latex->_errorcode $latex->_errorextra]",$pos,strlen($tex_matches[0][$i]));
        }
    */
    }
    return $url;
}

Right, that’s LatexRender all setup. Now we need to make the render.php file. Put the code in a file and save it in the same directory as class.latexrender.php and latex.php.
render.php:

<?
header("Content-type: image/png");
include_once('latex.php');

if (isset($_GET['l'])){

        $text = $_GET['l'];
        $text = stripslashes($text);
        $text = "[tex]" . $text . "[/tex]";

        $latex_img_file = latex_content($text);
        $handle = fopen($latex_img_file, "r");
        $contents = fread($handle, filesize($latex_img_file));
        fclose($handle);

        echo $contents;
}
?>

Obviously change the header function to match the content type you specified in class.render.php. This file accepts LaTeX formula code as an argument render.php?l=<formula>, puts it between [tex] tags so it can be messed around by latex.php and then renders it as the image file.

Now all that is left is to incorporate this into TiddlyWiki, using a simple macro. (Just change the src= section to match the location of your script):

config.macros.tex = {};
config.macros.tex.handler = function (place,macroName,params,wikifier,paramString,tiddler) {

     var code = encodeURIComponent(params[0]);
     wikify("<html><img class=\"teximg\" title=\"" + params[0] + "\" src=\"latexrender/render.php?l=" + code + "\"></html>", place);

}

To use this plugin just call it like so:

<<tex '\int_{-5}^{5} x^2 dx'>>

For some rendered examples just browse my wiki!
The macro also gives all equations the “teximg” css class, so they can be adjusted to be inline “nicely”, using the following CSS in the StyleSheet tiddler:

.viewer {line-height: 2.0 ;} .viewer img.teximg { vertical-align: middle;}

Hopefully you’ll now have easy LaTeX macro’s working on your TiddlyWiki! Any problems just leave me a comment.

Turns out I wasn’t the only one with the problem, and I found a solution here. (Thanks to wieman01 on the Ubuntu forums for this.)

What was happening was Ubuntu’s power management was a bit over zealous and was making the hard drive spin up and down far too often. By changing the power settings this can be fixed, using the command:

hdparm -B 254 /dev/xxx

replacing xxx with your drive name, in my case for my SATA drive it was /dev/sda.

254 here is the lowest level of power management, and 255 is off completely. You can try playing with higher values if you like some kind of power management.

To make this run every time the computer starts, add it to a startup script. For example, save a plain text file containing the above line to:

/etc/init.d/local_settings

Then:


cd /etc/init.d
sudo chmod +x local_settings
sudo ln -s local_settings /etc/rc2.d/S99local_settings


This makes the file executable, and creates a symbolic link to it in the folder which contains the start-up scripts, giving it priority 99.

Hopefully your clicking noise will now be gone!