Friday, December 24, 2010

HOWTO: Get working ASRock HT330 remote on XBMC and Ubuntu

HOWTO: Get working ASRock HT330 remote on XBMC and Ubuntu

Note: If you don't care for the details, scroll down and grab the entire script below.

First thing you need to do is get a console. If you are using XBMC, press CTRL+ALT+F1.
In the console, you need to log in with your username and password.

Once you are logged in, create a working folder:
mkdir ir
cd ir

You need lirc for remotes to work:
sudo apt-get install lirc

Now you need to get the CIR drivers from ASRock:

wget ""
unzip -j
unzip -j

I found the ASRock drivers here.

Now try to install it:
sudo dpkg -i lirc-nct677x-1.0.4-ubuntu10.04.deb

As explained in another blog you must choose "None" and then "None" again.

It will do work, and then ask you again for receiver type. This time select the
"Nuvoton Transceivers/Remotes" as the receiver and then "None" for the transmitter.

If it fails, your output will look like this:
* Stopping remote control daemon(s): LIRC[ OK ]
patching file /usr/share/lirc/lirc.hwdb
* Stopping execution daemon: irexec [fail]
* Stopping remote control daemon(s): LIRC [fail]
* Starting execution daemon: irexec [fail]

Now try to manually load the module:
sudo modprobe lirc_wb677

You will likely get an error like this:
FATAL: Error inserting lirc_wb677 (/lib/modules/2.6.31-16-generic/kernel/ubuntu/lirc/lirc_wb677/lirc_wb677.ko): Invalid module format

And if you run dmesg you will see:
[  534.630092] lirc_dev: IR Remote Control driver registered, major 61
[ 534.631027] lirc_wb677: disagrees about version of symbol module_layout

What has happened is that the kernel version does not match the version that the driver was made for, so now you need to build your own driver.

First, get the tools to build the driver:
sudo apt-get update
sudo apt-get install dkms build-essential lirc-modules-source

Then install the source for the driver:
unzip -j
sudo dpkg -i lirc-nct677x-src-1.0.4-ubuntu10.04.deb

You will now get the message:
You can use dkms commands to compile / install nct677x / w836x7 CIR driver now.
to build src : dkms build -m lirc-nct677x-src -v 1.0.0-ubuntu9.10
to install binary : dkms install -m lirc-nct677x-src -v 1.0.0-ubuntu9.10
to uninstall binary : dkms uninstall -m lirc-nct677x-src -v 1.0.0-ubuntu9.10
to remove src : dkms remove -m lirc-nct677x-src -v 1.0.0-ubuntu9.10 --all
After updating src, remember to update lirc.hwdb and
reconfigure lirc by the following command:
dpkg-reconfigure lirc

Apart from the fact that the version is 1.0.4, this looks nice, so lets try the build command:
sudo dkms build -m lirc-nct677x-src -v 1.0.4-ubuntu9.10

This gives the rather unhelpfull error:
Error! DKMS tree does not contain: lirc-nct677x-src-1.0.0-ubuntu9.10
Build cannot continue without the proper tree.

After some poking around, it turns out that the "tree" is actually located in /var/lib/dkms,
so we need to make a structure that fits DKMS:
sudo mkdir /var/lib/dkms/lirc-nct677x-src
sudo mkdir /var/lib/dkms/lirc-nct677x-src/1.0.4-ubuntu9.10
sudo cp -R /usr/src/lirc-nct677x-src-1.0.4-ubuntu9.10/ /var/lib/dkms/lirc-nct677x-src/1.0.4-ubuntu9.10/source

Now DKMS should be happy, so build and install the module (we force the module to overwrite the one installed by the package earlier):
sudo dkms build -m lirc-nct677x-src -v 1.0.4-ubuntu9.10
sudo dkms install -m lirc-nct677x-src -v 1.0.4-ubuntu9.10 --force

Lets try modprobe again:
sudo modprobe lirc_wb677

And this time there should be no errors.

Now re-configure lirc:
sudo dpkg-reconfigure lirc

Select the "Nuvoton Transceivers/Remotes" as the reciever and then "None" for the transmitter.

The output should show that it succeeds:
* Loading LIRC modules [ OK ]
* Starting remote control daemon(s) : LIRC [ OK ]
* Starting execution daemon: irexec [ OK ]

Now reboot the machine:
sudo reboot

And it should work!

If you upgrade your kernel at some point, you just need to rebuild the module again:
sudo dkms build -m lirc-nct677x-src -v 1.0.0-ubuntu9.10
sudo dkms install -m lirc-nct677x-src -v 1.0.0-ubuntu9.10 --force

As promised a full script. When asked for the reciever select "Nuvoton Transceivers/Remotes", and if
it is not on the list, select "None". It should show the selection dialog two/three times, with two selections
for each run (a total of 4/6 blue dialogs):

mkdir ir
cd ir
wget ""
unzip -j
unzip -j
unzip -j
sudo apt-get install dkms build-essential lirc-modules-source
sudo dpkg -i lirc-nct677x-1.0.4-ubuntu10.04.deb
sudo dpkg -i lirc-nct677x-src-1.0.4-ubuntu10.04.deb
sudo mkdir /var/lib/dkms/lirc-nct677x-src
sudo mkdir /var/lib/dkms/lirc-nct677x-src/1.0.4-ubuntu9.10
sudo cp -R /usr/src/lirc-nct677x-src-1.0.4-ubuntu9.10/ /var/lib/dkms/lirc-nct677x-src/1.0.4-ubuntu9.10/source
sudo dkms build -m lirc-nct677x-src -v 1.0.4-ubuntu9.10
sudo dkms install -m lirc-nct677x-src -v 1.0.4-ubuntu9.10 --force
sudo modprobe lirc_wb677
sudo dpkg-reconfigure lirc

Thursday, December 16, 2010

The Humble Indie Bundle, part #2

The Humble Indie Bundle is a promotion concept where you can by a bundle of games from independent developers, at a price that you choose.

The current campaign is #2 and contains five games:
I have purchased the set, and so far only tried Machinarium, but I must say that this game is worth at least $20 alone.

It is a fairly regular adventure game with an atmosphere much like Syberia. You control a robot that has an unknown task. For some reason the robot reminds me a little of the animated movie 9.

The hint system is a really nice touch. It is essentially a mini shooter game, but the idea is that it takes a little time before you can get the hint, so you are more likely to try to figure it out rather than just look it up.

The implementation is entirely flash, which I can imagine is nice for the graphical artists, but it does have small subtle bugs, such as items becoming un-clickable, so you must move around to re-activate them.

But overall the game is challenging and has a cool atmosphere, which I find are the two most attractive features.

If you have not already bought the Humble Indie Bundle, you need to hurry, as there is now less than 5 days till the offer expires!

Saturday, December 11, 2010

Why intellisense stops working in Visual Studio 2010

I have some trouble with intellisense in Visual Studio 2010. Occasionally it stops suggesting entries, so it is not really broken, it just does not highlight a suggestion, forcing me to either select it with the mouse, or use arrow keys. The first picture shows it when it is not working, the second picture shows it working:

intellisens not working
intellisense working

The annoying part is that once this happened, I could not fix it, except by restarting Visual Studio, which takes some time. After some searching, it turns out "it's not a bug, it's a feature!".
It is called low-impact intellisense, and it can be toggled with CTRL+ALT+space.

I'm pretty sure that I never type that by mistake, but at least now I know how to turn it back on once it stops working.

Friday, November 26, 2010

Why Thread.Abort() is NOT evil

I apply the using statement quite a lot:
using(FileStream fs = new FileStream(path, mode)) {
//Do work on fs here

This is a syntactic sugar for the try/finally construct, eg:
FileStream fs = null;
try {
fs = new FileStream(path, mode);
//Do work on fs here
if(fs != null)

Today I was researching the java.thread.stop() method, which is deprecated because it is unsafe.

While doing so, I found multiple post stating that the same is true for .Net applications. They all seem to refer to the article "How To Stop a Thread in .NET (and Why Thread.Abort is Evil)", which claims that the exception can occur in the finally block.

Fortunately this is NOT true, but I just had to make sure:
static volatile bool done = false;
static volatile bool inFinally = false;
static void Main()
Thread t = new Thread(new ThreadStart(RunThread));

//Wait for the thread to enter the finally block
while (!inFinally)

//Abort the thread in the finally block

//Provoke it by issuing a double abort exception

//Now make sure the thread is done

//Present the results
if (!done)
Console.WriteLine("Thread.Abort() is unsafe!");
Console.WriteLine("Thread.Abort() is NOT evil!");

//An emulated thread
private static void RunThread()
int x = 0;
try { x = 1000; } //A harmless operation
//Flag that we are ready for the exception
inFinally = true;
//Do some time consuming work to ensure that we
// stay in the finally block for a while
for (int i = 0; i < 10000; i++)
for (int j = 0; j < 10000; j++)

//If we did not get interrupted, set the flag
done = true;

And fortunately the output is:
Thread.Abort() is NOT evil!

Sunday, November 21, 2010

Utilizing Android LinearLayout

I have been using the Android LinearLayout for a test application. There is some documentation and a minor preview of what it does, but I don't think this makes it simple to understand.
I tried searching for a better explanation, but none came up, so here is my version.

The xml that I'm using as a base is this:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android=""
    android:layout_width="100px" android:layout_height="80px"



When you set the layout_height to fill_parent and the layout_weight to the same number, the available space is divided between the elements. This makes it possible to have two or more elements sharing the available space, where each gets the same amount of space:

This was about what I could gather from the demo page. But what if you want a fixed size header, and have the two following elements share whatever space is left? The solution is to set the layout_height of the fixed-size element to wrap_content, and then set the layout_weight to 0 for that element:

This is counter-intuitive to me, because the name layout_weight is really a priority instead, so each item with the same layout_weight share the remaining space evenly. Once all elements with priority (layout_weight) 0 are placed, all elements with priority 1 then share the remaining layout space.

This lead me to investigate the reason for choosing the word weight, and it turns out that the value doubles as a weight as long as it is less than 1.0:

Friday, November 12, 2010

Java Grievances part 2

At some point the concept of a foreach construct was implemented in Java. This is a really nice construct that allows one to change code like this:

int sum = 0;
Enumeration<Integer> it = some_list.getEnumerator();
    sum += it.nextElement();
into code like this:

int sum = 0;
for(Integer i : some_list)
    sum += i;

This is quite nice, unfortunately, it is an addon so many Java libraries has no support for this. Even some of the more prominent libraries such as org.xml.sax and java.util.Hashtable have no support for the enumeration feature, even if they are obvious candidates. Nice try, but does not really give any punch as it is mostly not usable.

This is some of the same problems that occurs when using generics, which is not supported by the Java bytecode, so all the generic types are removed during compilation (called type erasure). The benefit of this is that code can use generics internally but still expose a non-generic interface externally. If this was the programmers intention, it could be done anyway, but now the choice is not there. The reason for this is obviously compatibility, but the implications are that the libraries are forced to expose a legacy interface. The really nice way to do this would be to set a compile switch that toggles either generic output, or type erasure. Again, nice try but does not really give anything.

The other problem is in the design philosophy where Java opts for having a single get() method which then takes an enumeration value as input. The notable example is the Calendar.get function which takes a number of integer values as input and returns different things. This approach means that the programmer has to look up what values are allowed, or guess the naming convention used for this particular method. It also means that the get method must validate all input to ensure that the user supplied a valid value.

A much better approach would be to simply make different functions, as that is what it really is. Example:
Calendar today = Calendar().getInstance();
int day = today.get(Calendar.DAY_OF_WEEK);
int month = today.get(Calendar.MONTH) + 1;

int day = today.getDayOfWeek();
int month = today.getMonth() + 1;

That way the documentation is less required, there are no run-time errors as the programmer cannot supply an invalid value, a win-win. Well, one can dream :)

Monday, November 8, 2010

Java Grievances

I've been doing a bit of Java work lately, and I must say that I am not impressed.

The language itself is a bit dated, lacking features such as enums and properties, but the worst part is the libraries.

Something as basic as a date can be manipulated with either the java.util.Date or java.util.Calendar. There is probably a neat history to explain why one would want two different versions of the same structure, but it should not be that way. The stock library should have a one-fits-all approach.

When working with the Calendar type, the annoying use of factory patterns result in less readable code, such as:
Calendar date = Calendar.getInstance();
date.setDate(year, month - 1, day);
Rather than just:
Calendar date = new Calendar(year, month, day);

You can opt to use java.util.GregorianCalendar instead, which does allow a non-factory type initialization, but that is still one extra hurdle to work with.

As an incomprehensibly strange decision, the month numbering starts with 0, but day starts with 1 as does day of week. This makes it unnecessarily awkward to work with dates, for no apparent gain.

Friday, October 29, 2010

The CIL optimizer at work

I'm currently working on some low-level optimizations with CIL, and I bumped into a surprising instruction sequence.

The C# code that is compiled looks like this:
public static class Fac
    public static long Factorial(long number)
        if (number == 0)
            return 1;
            return number * Factorial(number - 1);

When compiled to CIL, it looks like this:
public static class Fac
.method public hidebysig static int64  
    Factorial(int64 number) cil managed
  // Code size       34 (0x22)
  .maxstack  3
  .locals init ([0] int64 CS$1$0000,
           [1] bool CS$4$0001)
  IL_0000:  nop
  IL_0001:  ldarg.0
  IL_0002:  ldc.i4.0
  IL_0003:  conv.i8
  IL_0004:  ceq
  IL_0006:  ldc.i4.0
  IL_0007:  ceq
  IL_0009:  stloc.1
  IL_000a:  ldloc.1
  IL_000b:  brtrue.s   IL_0012
  IL_000d:  ldc.i4.1
  IL_000e:  conv.i8
  IL_000f:  stloc.0
  IL_0010:  br.s       IL_0020
  IL_0012:  ldarg.0
  IL_0013:  ldarg.0
  IL_0014:  ldc.i4.1
  IL_0015:  conv.i8
  IL_0016:  sub
  IL_0017:  call       int64 CILFac.Fac::Factorial(int64)
  IL_001c:  mul
  IL_001d:  stloc.0
  IL_001e:  br.s       IL_0020
  IL_0020:  ldloc.0
  IL_0021:  ret
} // end of method Fac::Factorial

What struck me was this code sequence:
  IL_001e:  br.s       IL_0020
  IL_0020:  ldloc.0

Rather weird as it just jumps directly to the next instruction. While writing an optimizer that detects and erases such inefficient constructs, it dawned on me that the code was probably built in debug mode, so I tried it in release mode, which gives this output:
.method public hidebysig static int64  
    Factorial(int64 number) cil managed
  // Code size       20 (0x14)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldc.i4.0
  IL_0002:  conv.i8
  IL_0003:  bne.un.s   IL_0008
  IL_0005:  ldc.i4.1
  IL_0006:  conv.i8
  IL_0007:  ret
  IL_0008:  ldarg.0
  IL_0009:  ldarg.0
  IL_000a:  ldc.i4.1
  IL_000b:  conv.i8
  IL_000c:  sub
  IL_000d:  call       int64 CILFac.Fac::Factorial(int64)
  IL_0012:  mul
  IL_0013:  ret
} // end of method Fac::Factorial

And with that the inefficient instruction was gone, saving me a lot of work :).

Another interesting difference is that the release version has removed all use of the local variables at the expense of a larger stack depth. This is also rather nice as a JIT engine can assign stack values to registers, much more easily than with the local variables.

Lesson learned: when optimizing CIL (or any byte code) only look at the optimized version.

Wednesday, May 5, 2010

Registering the VeriSign Class 3 certificate on a Nokia phone

I recently installed an application on my Nokia phone that uses SSL to communicate with a server. The web page shows fine on my PC, but on the phone I get an annoying certificate error while using the web browser.

The problem seems to be a missing VeriSign Class 3 root certificate. I have found a strange description of the problem on the Nokia forum, and a related problem with a signed app. This also means that the GMail application does not work, as it relies on that particular certificate.

What neither of these links tell you, is that it is not too difficult to install the required root certificate yourself.

Simply browse to the page in question on your computer. Click the padlock (or similar) icon to view the certificate. Somewhere in this dialog you should see a "signature chain" or "signature path", and on top of the path/chain should be the missing root certificate. You need to export this to a file. For my Nokia 6500, the DER format worked fine.

Once you have the file, rename it to .crt and place it on a webserver. The webserver must use the following mime type:

Now simply browse to the file in question, using the built-in webbrowser on the phone, and it will ask you to install the certificate. You can remove it again by visiting the security settings via the phone menu.

If you want the VeriSign Class 3 root certificate, you can go to, as they have a certificate signed by that root certificate.

You can also try to download the official certificates and find the one you need:

I have not found an online copy that you can download directly from your phone, so I have put one here:

If you use the above link, be sure to validate the certificate, as I provide no guarantees as to the correctnes of the certificate, other than to say "it works for me". If the certificate is somehow compromised, bad guys may be able to manipulate and read secure communication from your device.

Friday, April 23, 2010

Uploading files with the .Net framework

The .Net framework has some very simple wrappers for performing http communication, but sometimes there are subtle aspects that introduce bugs.

One issue that I have recently discovered is the Timeout property, which has the following description on MSDN:
Gets or sets the time-out value in milliseconds for the GetResponse and GetRequestStream methods.

As I read that description, I get the impression that the call to GetRequestStream is blocked until a connection is made, or the Timeout occurs.

Unfortunately, this should be read as:
Gets or sets the time-out value for the completion of the request or response operation.

A simple code example:
HttpWebRequest req = WebRequest.Create("");
req.Timeout = 2 * 1000; //2 seconds
req.Method = "PUT";
using(Stream stream = req.GetRequestStream())
//This does not count towards the timeout,
// perhaps because the connection is not made until the first write
Thread.Sleep(5 * 1000);

//This does nothing, as the stream has the value cached
req.Timeout = 5 * 1000;

//This loop must finish before 2 seconds have passed!
// the timer starts when the first byte is written
{ /* Code that writes to stream */ }

Saturday, March 20, 2010

Heavy Rain (no spoilers)

I've just finished playing the awesome "Heavy Rain" game, and gotten all trophies.

If you have not yet played the game, please do!
This game is different from other games, in that you cannot fail the game, you just get another story.

Also be sure not to look up the meaning of certain things, such as the "inches" measurement, because they are explained in the game, and there is a good chance you will run into spoilers.

The gameplay is a bit too simplistic, but reminds me of the good old classics, such as "Simon The Sorcerer" and "Maniac Mansion: Day of the Tentacle". If there was more puzzle stuff it would be even better.

After you have had a full playthrough, you can try to get all the trophies.
There is a lot of advice on how to get the trophies, and a lot of theories about possible glitches.
In my experience, there are no thropy glitches, but there are certain conditions that you must fullfill in order to get them.

I only had two thropies that I had trouble with, "Birthday Party" and "Perfect Crime".
For "Birthday Party", I did not understand that you had to keep running with Shaun, it took me about two and a half lap around the garden before the end was triggered. And then the thophy does not appear until after the completion of "Father and son" much later in the game.

The problem I had with "Perfect Crime" was that Shaun must also die, which is not mentioned in the description.

There seems to be a bit of myth around the "All Endings" trophy. I got the trophy without all endings in one save game, so that is definately possible. Some say that you do not have to use save mode, but just watch them. That did not work for me.

I think you can get the trophy without saving, but once you exit the game, it has not saved that you have seen the endings. So you basically have to see the credits all the way through and replay the missing endings without quitting.

Have Fun!