Skip to content. | Skip to navigation

Personal tools
Log in
Sections
You are here: Home Blog archive 2011

2011

Sub-archives

Magic Lantern on EOS 500D

by Bastian Blank — last modified Dec 20, 2011 04:45 PM
Filed Under:

Magic Lantern is a firmware extension for Canon DSLR cameras. It provides many new features for video and liveview mode and also some for photo mode.

Magic Lantern is a firmware extension for several video capable Canon DSLR cameras. The (not longer) current release 11.11.11 of the unified branch works on 500D and most newer models except 5D Mk2.

The installation on my 500D was pretty easy. The camera needs the correct firmware installed (1.1.1), otherwise Magic Lantern will refuse to run. It needs one modification to the camera, a debugging setting to load the system from a SD card. The software is then loaded from a specially prepared SD-card every time the camera boots.

Magic Lantern includes a lot of nice extensions for video and liveview mode. My favorites are histogram overlay, edge detection and exposure display. The histogram overlay shows the histogram in different modes (RGB, luma) of the currently displayed view. Edge detection can be used to find the focus via the liveview output. However a lot more features are available.

Linux 3.0 and Xen

by Bastian Blank — last modified Jun 23, 2011 06:35 PM
Filed Under:

Linux 3.0 includes the traditional device backends and supports full Dom0-operation.

It took a long time to get all the parts of the Xen support into the Linux kernel. While rudimentary Dom0-support was available since 2.6.38, support for device backends were missing. It was possible to replace this backend with a userspace implementation included in qemu, but I never tested that.

With Linux 3.0, both the traditional block backend and the network backend are available. They are already enabled in the current 3.0-rc3/-rc4 packages in experimental, so the packages can be used as Dom0 and run guests. Right now the backend modules are not loaded, so this still needs some work. Neither the init scripts loads them, because the names where in flux the last time I laid hand on it, nor does the kernel themself expose enough information to load them via udev. I think using udev to load the modules is the way to go.

This step marks the end of a five year journey. Around 2.6.16 the Xen people started to stay really close to Linux upstream. With the 2.6.18 releas this stopped and the tree was pushed in different states into Debian Etch and RHEL 5. After that, Xen upstream ceased work on newer versions completely, only changes to the now old 2.6.18 tree where done. SuSE started a forward port of the old code base to newer kernel versions and Debian Lenny released with such a patched 2.6.26. Around that time, minimal support for DomU on i386 using paravirt showed up and Lenny had two different kernels with Xen support. Since 2.6.28 this support was mature and works rather flawless since. Somehow after that, a new port of the Dom0 support, now using paravirt, showed up. This tree based on 2.6.32 is released with Debian Squeeze. After several more rounds of redefining and polishing it is now mostly merged into the core kernel.

I don't know what the future brings. We have two virtualization systems supported by Linux now. The first is KVM that converts the kernel into a hypervisor and runs systems with help of the hardware virtualization. The later one is Xen that runs under a standalone hypervisor and supports both para- and hardware virtualization. Both works, KVM is easier to use and even works on current System z hardware. It can be used by any user with hopefully enough margin of security between them. Xen's home is more suited for servers, where you don't have users at all. Both have advantages and disadvantages, so everyone have to decide what he needs, there is no "one size fits all".