cyberwizzard.nl

Since it took me hours to find this answer, I decided to put it up clear and simple: this is how you 'force' your stock HTC Hero to check for updates.

First off, this is for the original HTC Hero. So not the Sprint or CDMA version, but the GSM version (with the chin). Most sites tell you to use the "Check for updates" option. The original HTC Hero firmware does not have this option.

Instead, you need to install the first (of three) updates to get the updater. The original update mechanism checks every two weeks for an update. If you need it to check right away, you can move the clock 2 weeks forward or use enter this number: *#*#682#*#*. If it worked, the number will disappear from the dialer and almost instantly a popup will tell you that an update is available.

After this update, force the phone to check for future updates by doing:

1. From the Home screen, press MENU, and then tap Settings.
2. Scroll down the screen, and then tap About phone > System software updates.
3. On the System software updates screen, tap Check now.

The Gentoo Wiki article about KVM uses the less flexible networking setup with dedicated TAP devices like 'tap0'. While this setup works fine, other distributions use the bridge device in a different way. By creating a virtual bridge and forcing the host system to connect through this bridge, virtual machines can simply connect to the bridge device and 'plug in'. No need to manually create TAP devices. In this guide we will set up host and guest networking using the virtual bridge device and DHCP for wired ethernet.

For this to work, you will need most of the tools from the wiki article as well as a couple more (I like the management GUI from virt-manager to manage VMs without a text console). Install the following tools:

1. app-emulation/qemu-kvm - QEMU + Kernel-based Virtual Machine userland tools
2. net-misc/bridge-utils - Virtual network bridging
3. app-emulation/virt-manager - libvirt management GUI
4. app-emulation/libvirt - Toolkit to manipulate virtual machines, supporting virtualisation frameworks like KVM and Xen

Install all the tools and modify the kernel to support the bridge devices. Note that tunnel support is omitted (unlike in the original wiki article).

 [ * ] Virtualization --->
       --- Virtualization
           <m> Kernel-based Virtual Machine (KVM) support
           < > KVM for Intel processors support
           < > KVM for AMD processors support
 Networking support --->
       Networking options --->
           <*> 802.1d Ethernet Bridging
           <*> 802.1Q VLAN Support

Build the kernel, the modules and install both. Do not forget to reboot.

Next up, lets configure the network on the host machine. Disable NetworkManager as it will not understand the bridge device and break networking altogether in an attempt to activate things they usually are.

We will connect the network as shown below. The interface 'eth0' is now a passthrough for the virtual network bridge - note that the eth0 device has no IP address. The new 'br0' device is a new bridge. This is the new networking interface for the host PC - it gets an IP address and is the designated end point for communication. Other virtual NICs connect to this bridge.

             HOST
       +---------------+
LAN ---+--- eth0       |
       |      ^        |        KVM GUEST1
       |      |        |   +--------------+
       |    +-----+    |   |              |
       |    |vnet0+----+---+---- nic0     |
       |    |vnet1+----+-+ |192.168.100.2 |      KVM GUEST2
       |    +-----+    | | +--------------+   +--------------+
       |     br0       | |                    |              |
       |192.168.100.1  | +--------------------+---- nic0     |
       +---------------+                      |192.168.100.3 |
                                              +--------------+

In order to automatically configure the network, edit '/etc/conf.d/net' and insert the following:

# Disable all configuration on eth0
config_eth0=("null")
# Use eth0 to connect the virtual bridge
bridge_br0="eth0"
# Statically configure br0
config_br0=("192.168.100.1 netmask 255.255.255.0")
routes_br0=("default via 192.168.100.254")
dns_servers_br0="192.168.100.254"
# Uncomment the next line and comment the lines above to use DHCP
#config_br0=("dhcp")

Now we need to symlink '/etc/init.d/net.lo' to '/etc/init.d/net.br0'. We can now stop 'net.eth0' if you still had it running and start 'br0' instead. Note that the Gentoo networking scripts create the bridge interface 'br0' and bring everything up (including eth0, but without assigning an IP).

The Gentoo scripts do this under water (in case you want to manually configure things):

# Create the br0 device and connect eth0 to it
brctl addbr br0
brctl addif br0 eth0

If you want to make this networking setup permanent, remember to remove 'eth0' from the default runlevel and add 'br0' instead.

Now start the service 'libvirt' and run 'virt-manager' to start managing Virtual Machines. If everything worked as planned, creating new VMs will automatically (read: libvirt creates these) result in new virtual NICs for the virtual network. Good luck!

While the title may sound a tad cryptic, that matched my first impression about the new infrared remote subsystem used in Ubuntu 10.10 and kernel 2.6.36+ based distributions. In Linux 2.6.36, a new sub-system is introduced for remote controls. This subsystem is a partial replacement for lirc as it features complete IR drivers for numerous devices.

In reality, the glass is only half full as some IR receivers (and transmitters) deal with raw data. Writing universal drivers for such devices can be bothersome or even impossible, for example when dealing with universal receivers. As such, LIRC is not completely written off as it can be used to do userspace IR processing as it used to. The exact details are unknown to me as I have an SoundGraph iMon receiver (device ID 0038 - LCD), which does not deliver raw sensory input but rather complete scancodes.

When I upgraded from Ubuntu 10.04 running lirc 0.8.6 to Ubuntu 10.10 and lirc 0.8.7, the entire IR subsystem died on me. To my surprise, while the remote was dead, the LCD screen was working fine. Further inspection showed that the 'lirc_imon' driver was not loaded at all.

With the move to the new input layer driver for supported IR devices in the kernel, the new 'imon' driver (version 0.8 at the time of writing) no longer provides a 'lirc0' device. As such, lircd will fail when attempting to claim it and loading 'lirc_imon' (provided you still have it) will not work as the device is already claimed by the 'imon' driver.

The fastest way to get up and running again is as follows. The 'imon' receiver will now be a HID input device. I got the impression it would send keystrokes to a graphical application but I didn't get that working. Instead, we will use 'lircd' again using a special driver called 'devinput'. This driver reads the key strokes from the input layer device and converts them into LIRC events. All your LIRC capable programs will then use lirc like they used to - we only need to use the new button names.

To find the iMon receiver in the list of input devices, lets create a udev rule to symlink to the device. This way we will not have to rely on obscure device names like 'input1'. Make sure the device name matches whatever hardware you have. I inserted this rule in a file called '/etc/udev/rules.d/99-imon.rules':

KERNEL=="event*", SYSFS{name}=="iMON Remote (15c2:0038)", NAME="input/%k", SYMLINK="input/imon_remote", MODE="0666"

Lets begin by stopping lirc if you still have it running. Next, reconfigure LIRC to use the devinput driver - when it asks which device you have DOT NOT SELECT THE SOUNDGRAPH IMON but 'Linux input layer (/dev/input/eventX)'. In the next screen select 'None' as you probably do not use a transmitter.

/etc/init.d/lirc stop
sudo dpkg-reconfigure lirc
> Linux input layer (/dev/input/eventX) 			 		
> None
/etc/init.d/lirc start

In case you are not using Ubuntu linux, I will explain the key parts of the LIRC configuration. The '/etc/lirc/lircd.conf' file now has this part in it:

#Configuration for the Linux input layer (/dev/input/eventX) remote:
include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput"

The 'lirc.conf.devinput' file is a standard (generated) file with key codes as provided with LIRC. There is no need to manually set up a file with button scan codes as the new ir-core kernel subsystem will generate standard codes.

The file called '/etc/lirc/hardware.conf' has something like this in it:

REMOTE="Linux input layer (/dev/input/eventX)"
REMOTE_MODULES=""
REMOTE_DRIVER="devinput"
REMOTE_DEVICE="/dev/input/imon_remote"
REMOTE_LIRCD_CONF="devinput/lircd.conf.devinput"
REMOTE_LIRCD_ARGS=""

All that remains is to use the new buttons in your LIRC capable program. For example, this is a part of my configuration of XBMC (Lircmap.xml) for use with the SoundGraph iMon receiver:

<lircmap>
        <remote device="devinput">
                <hash>KEY_EJECTCD</hash>
                <play>KEY_PLAY</play>
                <pause>KEY_PAUSE</pause>
                <stop>KEY_STOP</stop>
                <forward>KEY_FASTFORWARD</forward>
                <reverse>KEY_REWIND</reverse>
                <skipplus>KEY_NEXT</skipplus>
                <skipminus>KEY_PREVIOUS</skipminus>
                <record>KEY_RECORD</record>...

According to the devs of Amarok, the new VLC based backend for Phonon delivers better sound quality than the Xine backend. Something like this just begs to be explored of course and the instructions below are based on the generic ones but specifically for Gentoo. Please note that the backend is alpha: it is incomplete and changes daily.

Install VLC 1.1 pre by installing the live version (note that VLC 1.1 is about to be released any time now so this might be available by the time you read this). Note that I had to disable the Gentoo patches in the vlc-9999 ebuild as they prevent VLC from compiling.

ACCEPT_KEYWORDS=** emerge =vlc-9999

Note to self: add the keywords to the '/etc/portage/package.keywords' file. ;-)

Next, fetch the Phonon-VLC backend from GIT. Note that is should become 'stable' soonish (it said somewhere it should be moving to kdereview in the near future) so it should be safe to assume it sort of works.

cyberwizzard@cyberxps ~ $ mkdir kde
cyberwizzard@cyberxps ~ $ cd kde
cyberwizzard@cyberxps ~/kde $ mkdir src
cyberwizzard@cyberxps ~/kde $ cd src
cyberwizzard@cyberxps ~/kde/src $ git clone git://gitorious.org/phonon/phonon-vlc.git
Initialized empty Git repository in /home/cyberwizzard/kde/src/phonon-vlc/.git/
remote: Counting objects: 483, done.
remote: Compressing objects: 100% (400/400), done.
remote: Total 483 (delta 330), reused 116 (delta 66)
Receiving objects: 100% (483/483), 102.22 KiB, done.
Resolving deltas: 100% (330/330), done.
cyberwizzard@cyberxps ~/kde/src $ cd phonon-vlc/
cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ cmake -DCMAKE_BUILD_TYPE=debugfull -DCMAKE_INSTALL_PREFIX=/usr $HOME/kde/src/phonon-vlc/
...configure here...
cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ make
...wait a but more...
cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ su -c "make install"
Password: 
[100%] Built target phonon_vlc
Install the project...
-- Install configuration: "debugfull" 
-- Installing: /usr/lib/kde4/plugins/phonon_backend/phonon_vlc.so
-- Set runtime path of "/usr/lib/kde4/plugins/phonon_backend/phonon_vlc.so" to "/usr/lib:/usr/lib64/qt4"
-- Installing: /usr/share/kde4/services/phononbackends/vlc.desktop
cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ su -c "kbuildsycoca4 --noincremental"
...password and lot of output here...

And thats it! Just fire up Amarok -> Settings -> Configure Amarok -> Playback -> Configure Phonon (or go through System Settings in KDE) and select the VLC backend (currently shows up as version 0.2).