Rooting the HTC Hero

On friday I got my new HTC Hero in the mail. Yesterday, I rooted it following instructions on phandroid.com. Instead of from Windows, like in the article on phandroid.com, I did it from Linux, and here is how.

1. Download android-sdk-linux_x86-1.5_r3.zip

2. Download orange-htc-hero-uk-boot.img-28-july-2009.zip

3. Download fastboot for Linux.

4. Run these commands:

# unzip android-sdk-linux_x86-1.5_r3.zip
# unzip orange-htc-hero-uk-boot.img-28-july-2009.zip
# mv orange-htc-hero-uk-boot.img-28-july-2009/boot.img.insecure android-sdk-linux_x86-1.5_r3/tools
# unzip fastboot.zip
# mv fastboot android-sdk-linux_x86-1.5_r3/tools
# cd android-sdk-linux_x86-1.5_r3/tools

5. Shutdown the phone and plug in the USB cable.

6. Press and hold the back key and power on the phone.
This will get you into the fastboot USB screen (the white screen with three androids at the bottom).

7. Run this command:

# sudo ./fastboot boot boot.img.insecure
downloading 'boot.img'... OKAY
booting... OKAY

Now your device will start from the given image with root access.

8. In the phone's alerts menu, click HTC Sync.

9. Run this command:

sudo ./adb shell

This will give you a root shell on the device.

10. From this shell, run these commands:

# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# cp -a /system/bin/su /system/bin/su.backup
# cat /system/bin/sh > /system/bin/su
# chmod 4755 /system/bin/su
# reboot

Now your device is rooted!

BADSIG 40976EAF437D05B5

When running apt-get update today, I got this error message:

The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key

Strange. And it was no good retrying, the same error occurred over and over again. apt-get stopped complaining after running update with this option:

apt-get update -o Acquire::http::No-Cache=True

and this:

apt-get update -o Acquire::BrokenProxy=true

I suspect my company's Barracuda Spam & Virus Firewall is to blame, as it has been blamed for arbitrarily corrupting downloads before by my co-workers. How can I know for certain?

H.264 at 1080p with NVIDIA's VDPAU on Linux

NVIDIA released support for their Video Decode and Presentation API for Unix with version 180.06 of their video and OpenGL driver for Xorg. They have also released patches to MPlayer so we can actually use it. I have tried getting it to work on my Gentoo GNU/Linux x86_64, but with the earliest drivers I got a green video window followed by a Xorg freeze with my graphics card. I had to SSH into the computer and kill MPlayer and Xorg. One of the versions even froze the kernel up completely. Version 180.27 actually didn't freeze my computer, put instead of the decoded video I got a random mosaic of colors.

With version 180.29 it did function properly with my XFX GeForce 280 GTX XXX graphics card. It's working great, and I can play H.264 1080p video with MPlayer using only 3% of a single CPU core!

To get VDPAU working you need, as I mentioned, a recent driver and at least version 180.06. Also you need a patched MPlayer, witch you can obtain the sources for here. Get the header files under "include" as well, and unpack the tarball and run the script checkout-patch-build.sh to retrieve MPlayer sources, patches and compile it all. As it is now (version 3482714), the VDPAU patches need additional patching to be able to play H.264 video above level 4.1:

--- libvo/vo_vdpau.c.orig 2009-02-17 15:03:25.936006847 +0100
+++ libvo/vo_vdpau.c 2009-02-17 18:43:43.995005259 +0100
@@ -90,7 +90,7 @@
 /* Numbers of video and ouput Surfaces */
 #define NUM_OUTPUT_SURFACES                3
 #define NUM_VIDEO_SURFACES_MPEG2           3  // (1 frame being decoded, 2 reference)
-#define NUM_VIDEO_SURFACES_H264            17 // (1 frame being decoded, up to 16 references) 
+#define NUM_VIDEO_SURFACES_H264            18 // (1 frame being decoded, 16 reference frames, plus b_frames and b_pyramid)
 #define NUM_VIDEO_SURFACES_VC1             3  // (same as MPEG-2)
 #define NUM_VIDEO_SURFACES_NON_ACCEL_YUV   1  //  surfaces for YV12 etc. 
 #define NUM_VIDEO_SURFACES_NON_ACCEL_RGB   0 // surfaces for RGB or YUV4:4:4
@@ -701,10 +701,7 @@
             uint32_t round_width = (vid_width + 15) & ~15;
             uint32_t round_height = (vid_height + 15) & ~15;
             uint32_t surf_size = (round_width * round_height * 3) / 2;
-            max_references = (12 * 1024 * 1024) / surf_size;
-            if (max_references > 16) {
-                max_references = 16;
-            }
+     max_references = 16; // Support for H.264 Level 5.1
         }
         break;
     default:

BuyPass switces to Java to interface with SmartCard

BuyPass is switching to using a Java implementation to interface with their BuyPass SmartCards. This is good news for everyone using a 64-bit Linux operating system. Their current access library called jnipcsc is only available for 32-bit architectures, and even then it's a pain to get working. They estimate that the new version of the BuyPass Java applet is ready for release in march 2009.

Emacs-w3m, a simple Emacs interface to w3m

The Emacs-w3m interface to the text based WWW browser is quite handy for reading those nasty HTML-only emails in Gnus.

The latest 1.4.4 release of Emacs-w3m is very old (2005), and doesn't work with Emacs 23. For Gentoo users of the development branch of Emacs 23 and Gnus, the only compatible version is in the CVS. There is currently no ebuild to install it. So, here is an ebuild to install it properly using Portage, if you want it.

emacs-w3m-9999.ebuild

# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header$

inherit elisp cvs autotools

DESCRIPTION="Emacs-w3m is an interface program of w3m on Emacs"
HOMEPAGE="http://emacs-w3m.namazu.org"
ECVS_SERVER="cvs.namazu.org:/storage/cvsroot"
ECVS_MODULE="emacs-w3m"
ECVS_BRANCH="HEAD"
S="${WORKDIR}/${ECVS_MODULE}"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="alpha amd64 ppc sparc x86"
IUSE=""

DEPEND="virtual/w3m"
RDEPEND="${DEPEND}"

SITEFILE=71${PN}-gentoo.el

src_unpack() {
    cvs_src_unpack
    cd "${S}"
    eautoreconf
}

# This is NOT redundant: elisp.eclass redefines src_compile() from default
src_compile() {
    econf || die "econf failed"
    emake || die "emake failed"
}

src_install() {
    emake lispdir="${D}"/${SITELISP}/${PN} \
        infodir="${D}"/usr/share/info \
        ICONDIR="${D}"/usr/share/pixmaps/${PN} \
        install install-icons || die "emake install failed"

    elisp-site-file-install "${FILESDIR}/${SITEFILE}"
    dodoc ChangeLog* README*
}

pkg_postinst() {
    elisp-site-regen
    einfo "Please see /usr/share/doc/${PF}/README*"
    einfo
    elog "If you want to use the shimbun library, please emerge app-emacs/apel"
    elog "and app-emacs/flim."
    einfo
}

pkg_postrm() {
    elisp-site-regen
}

Finally 64-bit Flash for Linux

Adobe has finally released a alpha of its first 64-bit Flash Player. This is in no way too soon. Users running 64-bit operating systems have been requesting this for several years to apparently deaf ears. Until now. Now, all that's left is for them to open source it, but I guess that's asking a bit much. I for one will surely be enjoying my Flash content from my 64-bit browser instead of having to start the 32-bit browser to be able to watch YouTube-clips.

On the other hand, the Gnash project has had a 64-bit Flash Player for quite some time now, and it's even capable of playing videos at YouTube. I suppose that in a couple of years when it's more stable, I'll be switching to using that one instead.