In the end I made these changes (relative to the directory /usr/share/X11/xkb/keycodes):

--- keycodes.dir.org    2009-09-03 08:31:32.000000000 +0200
+++ keycodes.dir    2009-10-06 12:58:54.000000000 +0200
@@ -46,6 +46,7 @@
 -------- -------- sony(nwp5461)
 -d------ -------- evdev(evdev)
 -------- -------- evdev(pc98)
+-------- -------- evdev(type6)
 -d------ -------- xfree86(xfree86)
 -------- -------- xfree86(basic)
 -------- -------- xfree86(102)
-- keycodes/evdev.org   2009-09-03 08:31:32.000000000 +0200
+++ keycodes/evdev  2009-10-06 12:59:32.000000000 +0200
@@ -311,3 +311,10 @@
     include "evdev(evdev)"
 };

+// Sun Type 6
+xkb_keycodes "type6" {
+    include "evdev(evdev)"
+    <RCTL> = 108;
+    <RALT> = 134;
+    <RWIN> = 105;
+};
--- rules/evdev.org 2009-09-03 08:31:34.000000000 +0200
+++ rules/evdev 2009-10-06 13:00:04.000000000 +0200
@@ -105,6 +105,7 @@
 ! $dvoraklayouts = br ca de ee es fr gb no pl se us

 ! model        =   keycodes
+  type6        =   evdev(type6)
   pc98     =   evdev(pc98)
   *        =   evdev

With the above changes I was additionally able to modify the file /etc/hal/fdi/policy/10-x11-input.fdi so that HAL will do the right thing, once this keyboard is plugged in (see the line with input.product).

<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">evdev</merge>
      <merge key="input.xkb.layout" type="string">de</merge>
      <match key="input.product" contains="HID 0430:0005">
        <merge key="input.xkb.model" type="string">type6</merge>
      </match>
    </match>
  </device>
</deviceinfo>

Make sure, that your desktop environment uses the system settings and doesn’t override it with session local settings, when you log into your desktop. If everything is correct, the /var/log/Xorg.0.log should contain something like this:

...
(II) config/hal: Adding input device HID 0430:0005
(**) HID 0430:0005: always reports core events
(**) HID 0430:0005: Device: "/dev/input/event0"
(II) HID 0430:0005: Found keys
(II) HID 0430:0005: Configuring as keyboard
(II) XINPUT: Adding extended input device "HID 0430:0005" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "type6"
(**) Option "xkb_layout" "de"
...

While the above changes may be the 100% solution, there is still the danger, that the changes are overwritten, when new keyboard tables are installed. For Gentoo Linux it is therefore advisable to extend the CONFIG_PROTECT variable in /etc/make.conf with the directories /usr/share/X11/xkb/keycodes and /usr/share/X11/xkb/rules.

The simplest solution however may be to copy the file /usr/share/X11/xkb/keycodes/evdev to a new file /usr/share/X11/xkb/keycodes/evdev-new, edit the keycode changes into this file and then load the keycodes by executing “setxkbmap -keycodes evdev-new(type6)” somewhere in the login process (.xprofile or .xinitrc or whereever).

The first good thing I noticed after rebooting into my standard Gentoo environment was, that all of my 9 mouse buttons were correctly working. The bad news was, that each time I pressed the Cursor Up key, that the KDE screen snapshot utility would open. I tried multiple changes in the Input section of the /etc/X11/xorg.conf file, all to no avail. The first break through came, when I completely removed all sections from the xorg.conf file having something to do with the keyboard or the mouse. After that it was only additional configuration for the HAL subsystem, to report the correct keyboard type. For this I created the file /etc/hal/fdi/policy/10-x11-input.fdi with this content:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.model" type="string">evdev</merge>
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.rules" type="string">evdev</merge>
    </match>
  </device>
</deviceinfo>

I think, the best way to diagnose any problems is to look at the /var/log/Xorg.0.log file. For my particular keyboard/mouse the output looks like this:

(II) config/hal: Adding input device HOLTEK Wireless Keyboard/Mouse(2.4G)
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): always reports core events
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): Device: "/dev/input/event2"
(II) HOLTEK Wireless Keyboard/Mouse(2.4G): Found keys
(II) HOLTEK Wireless Keyboard/Mouse(2.4G): Configuring as keyboard
(II) XINPUT: Adding extended input device "HOLTEK Wireless Keyboard/Mouse(2.4G)" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): xkb_rules: "evdev"
(**) Option "xkb_model" "evdev"
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): xkb_model: "evdev"
(**) Option "xkb_layout" "de"
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): xkb_layout: "de"

The xkb_* options are the important places here. Before I managed to set xkb_layout to “de” through HAL, the log file would report “us” here, which in turn had the affect of opening the snapshot dialogue when pressing Cursor Up. Another problem was the xkb_rules option. Some blog article I found through googling suggested to set xkb_rules to xorg. This does not work however, since xorg is a symbolic link in the /usr/share/X11/xkb/rules directory and links to base, which is not the correct rules set for the evdev-driver.

These three articles (part1, part2 and part3) from the Cybso blog were very helpful. In particular if you are using lineak. You should look at part 3 and install the lineakd keyboard file for the evdev-driver. These two links were helpful as well (1, 2

The Gentoo folks have created an update guide in the meantime, which wasn’t available, when I started out.

Man kann sich auch zu Tode sparen. Also habe ich das Medion Gerät erworben. Die Entscheidung wurde mit zusätzlich durch diesen recht positiven Testbericht erleichtert. Die ersten Navigationsversuche hier in der Umgebung sind ebenfalls positiv verlaufen. Einzig die kurze Akku-Laufzeit von unter 2 Stunden hätten mich fast dazu bewogen, das Gerät wieder zurück zu geben. Mit der dieser Laufzeit fällt der Einsatz als mobiles Navigationsgerät auf dem Fahrrad oder für Wanderungen praktisch weg. Für solche Anwendungen würde allerdings auch die Größe des Gerätes etwas stören.

Was mich aber letztendlich bewogen hat, das Gerät endgültig zu behalten, war das TTS (Text To Speech) Feature. Ich empfand es als sehr hilfreich, speziell bei der Navigation in ländliche Gegenden, wenn eine Ansage “Rechts Abbiegen in den Birkenweg” kam und nicht nur einfach “Jetzt Rechts Abbiegen”. Meine potentiellen Alternativen, das Navigon 7110 oder das 2110max, hätten diese Funktion nicht unterstützt. Spracheingabe, MP3-Player und Bluetooth für Handy-Freisprechen sind zusätzliche Gimicks, die ich nicht wirklich brauche, zumal MP3 und Bluetooth bereits durch das Autoradio unterstützt werden.

Ansonsten sind mir persönlich noch folgenden Punkte besonders aufgefallen:

• Das Gerät kann nur im Auto aufgeladen werden, da ein entsprechendes Netz-Ladegerät nicht zum Lieferumfang gehört. Abhilfe hat hier für mich das Netz-Ladegerät geschaffen, das zur der Hollux 236 GPS Bluetooth-GPS Maus geliefert wurde. Andere Geräte, die das Laden über einen normalen USB-Minianschluss ermöglichen, funktionieren sicherlich auch.
• Der Stift verschwindet nicht im Gerät, sondern wird von der Halterung gehalten, die das Gerät mit dem Schwanenhals verbindet. Nun ist es in Verbindung mit unserem Volvo V70 aber so, wenn das Navi an der Windschutzscheibe befestigt ist, kann man den Stift wegen der Schräge der Scheibe nicht mehr herausziehen.
• In verschiedenen Testberichte wurde bei anderen Medion Navis die Ansagelautstärke bemängelt. Für mich waren die Ansagen immer laut genug, selbst wenn das Autoradio in Betrieb war. Ich habe die Lautstärke des Gerätes sogar noch etwas reduzieren können.
• Die Bedienung über den Touch-Screen funktioniert sehr gut. Es bestand noch nie die Notwendigkeit auf den Stift zurück zu greifen.

Hopefully enough Linuxers decide to buy this great product, so that Lightzone continues to be available as a full product.

It really became very annoying during my Audacity sessions. The loading of a 2 hours MP3 started pretty fast, I guess until the buffer cache was filled, then the IO activity basically grind to a halt. Internet radio streams continued playing, but even switching desktops didn’t produce any reaction until the MP3 was nearly loaded into Audacity.

Apparently I’m not alone with my experiences. There is an extended thread in the Gentoo forums. From this thread I collected some hints and configured the system with

echo 2 > /proc/sys/vm/dirty_ratio
echo 1 > /proc/sys/vm/dirty_background_ratio
echo deadline > /sys/block/sda/queue/scheduler
echo 1 >/sys/block/sda/device/queue_depth

I even reduced the main memory by starting the kernel with the mem=2G argument, but all these changes had practically no effect.

I then made a little test (not very scientific) and took a vmstat 5 log during the load of a given MP3 file into Audacity with the above config. It took Audacity 8 minutes and 24 seconds to read the file. Audacity’s data directory was filled with 3.34 Gb of audio data after the load. This is the text output. I loaded the data into OpenOffice and produced the diagram to the right. During the beginning of the loading the block out (bo) rate is very high (in the 20,000 range), then after a while it drops to 2000-4000 blocks. Once it drops the system is basically over 90% in wa (wait i/o).

Update 2008-03-24: In my original post I compared Gentoo 64bit running in 2Gb of memory against Knoppix running in 4Gb. I repeated my little test with Audacity a couple more times. To the very left is a diagram running the test under Gentoo 64bit with 4Gb of memory. The result is not really different as compared with 2Gb of main memory. A couple of seconds faster maybe. The Audacity progress bar in the end reported 8:08 for loading the MP3 file. vmstat text output

The next diagram belongs to a test, where I changed the I/O-schedulter to CFQ and set queue_depth to 31. (Ok ok, first rule of benchmarking: Never change more then one parameter for each test run. Me Culpa). This improved the situation in so far, that it took Audacity only 6:50 to load the MP3 file. However, the system is still most of the time in wait-I/O. vmstat text output

Now, it gets interesting. For the next two runs I created a 6Gb image file with dd and then created a XFS file system inside the image. This file system was then mounted onto the directory into which Audacity loads its audio data. Now, this tests showed a performance, which I would expect from this particuar hardware setup. It took Audacity only 1:22 to complete the loading. The bo rate was nearly the complete runtime in the high 80,000 range. vmstat text output

Now repeated the test one last time, but instead with a XFS-fs I reformatted the image file with a EXT3 file system. Again, the test completed pretty fast, but not as fast as with the XFS-fs. It took Audacity 1:46 to load the MP3 file. However, if you look at the diagram and compare it to the XFS diagram, you’ll see, that quite a bit of more wait-I/O is involved. vmstat text output

I’m wondering, if XFS simply the better file system for this kind of data intensive application or if the still somewhat higher wait-I/O rate for the EXT3 fs is an indication of the same problem, that causes so very high wait-I/O, when the test is run in the EXT3 root file system. Can a switch to XFS be the solution for my problem or do I really need to change to 32bit Linux. End of Update

To have a comparison I booted the Knoppix 5.3 DVD, which uses 2.6.24 as well, but in 32bit. I mounted the hard disk, configured Audacity to have the data directory on it and repeated the test. Here is the text output of vmstat 5 from that run. Here the system behaves just as it should. The block out (bo) count is in the 30,000 to 35,000. The whole operation completed in 1 minute and 46 seconds. Unfortunately I forgot to reduce the memory to 2Gb to make this measurement a little more comparable with the previous take. Anyway I don’t think, that this would explain the different between 1:46 and 8:24.

As a last resort I moved the kernel config file from the Knoppix DVD to the Gentoo system and recompiled a kernel with this config, changing only those parameters to change the kernel into a 64bit version, the rest remaining the same. I restarted the Audacity run, but half way through the test I saw, that it was just slow as with the original Gentoo kernel. So this really appears to be a 32bit vs. 64bit issue.

So, in the end I guess I’m going to move back to a 32bit kernel.

At work I’m using a Intel P4 2.8Ghz system with 1 Gb of memory. The system is running Gentoo Linux and goes without reboots for longer periods of time. The system is usually rebooted, when I compiled and installed a new kernel. At the end of the day I hibernate the system and let it wake the next morning by setting an alarm in /proc/acpi/alarm.

Yesterday I nearly reached the point were my complete virtual and physical memory was exhausted and these were the processes, that ate most of the memory (very rough numbers):

• Eclipse 3.3 with lost of plugins installed. Virtual memory was somewhere in the 800Mb region and resident memory at about 280Mb.
• Firefox 2.0.11. Virtual memory was at 520Mb and resident memory at about 250Mb.
• Amarok 1.4.8. Virtual memory allocated: 1.2Gb. Resident memory somewhere between 200 and 300Mb.

And with the rest of processes required to make a usable system I was at nearly 100% memory utilisation. Why in the world would an audio player use 1.2Gb of virtual memory?

So, for the time being until I’m done with my Eclipse work I’ve switched to Audacious. Audacious is happy with about 120Mb virtual and 37Mb resident memory.

I like to share my experiences in some forthcoming posts. It was not completely smooth sailing. For the moment here are some random shots from the two system during the assembly.

Irgendwie war ich in der Vergangenheit immer ein bisschen zu geizig, um in ein eigenständiges Navigationsgerät zu investieren. Die Wege zu den Eltern und Schwiegereltern kennen wir sowieso und für das eine Mal Urlaub im Jahr und die eine oder andere außergewöhnliche Route reichen dann auch Ausdrucke von Google Maps oder Map24.

Als ich Birgit dann im August ein neues Handy geschenkt, habe ich ein Smartphone ausgesucht, mit dem Hintergedanken, das mal mit dem Gerät ja vielleicht noch mehr anstellen kann als nur zu telefonieren. Zumal das Sony-Ericsson M600i, das ich ausgewählt habe, zu diesem Zeitpunkt bereits recht günstig zu bekommen war. Im Internet hatte ich bereits verschiedene Lösungen gefunden, die ein Handy zu einem vollwertigen Navigationgerät erweitern. Ein Testbericht in der c’t hat diesen Lösungen zu Teil auch gute Praktikabilität bescheinigt.

Als jetzt Ende November ein Trip nach Hamburg anstand, habe ich die Ideen dann in die Tat umgesetzt. Als Bluetooth GPS-Empfänger habe ich mich für den Holux 236 entschieden. Zusätzlich habe ich von SE den Adapter für die Stromversorgung des Handys über den Zigarettenanzünder und die passende Auto-Halterung von Brodit erworben.

Als Navigationslösung habe ich mich für Nav4All entschieben, die lt. Webseite bis zum 1.1 2010 kostenlos nutzbar ist. Hier handelt es sich um eine Standard MIDP 2.0 Java Anwendung, die damit auf jedem entsprechend ausgestatteten Handy benutzt werden kann und nicht nur auf Smartphones. Eingesetzt wurde die aktuelle Version 8.0.6. Es handelt sich hierbei um eine Offboard Lösung, d.h. für jeden Navigationsvorgang wird für die Berechnung der Route über das Handy einmal mit der Nav4All Servern im Internet Kontakt aufgenommen und die Routeninformationen heruntergeladen. Danach wird nur dann wieder Kontakt aufgenommen, wenn eine Neuberechnung der Route notwendig wird, weil man sich z.B. verfahren hat. Im Normalfall hat man eine simple grafische Navigation ohne Kartenansichten. Wenn eine Kartenansicht ausgewählt wird, müssen die Daten wiederum über das Internet geladen werden. Ohne weiteres Nachladen ist auch einen Listenansicht der Route möglich. Zur Definition der Route können die Daten im Adressbuch des mobilen Telefons herangezogen werden. Ansonsten erfolgt die Definition im Dialog mit Kontakt ins Internet. Die einmal verwendeten Routenziele werden von der Applikation gespeichert und können später wiederverwendet werden.

Insgesamt hat die Verwendung von Nav4All für die Navigation nach Hamburg wunderbar geklappt. Die Anweisungen kamen passend und früh genug. Es ist grundsätzlich einfach so, das man sich wirklich auf die Navigation über so ein Gerät, sei es nun Handy oder vollwertiges Navigationsgerät, einlassen muss. Anfänglich fühlt man sich irgendwie unwohl, sich vollkommen auf so ein Gerät zu verlassen und ihm blind zu vertrauen.

Während längerer gleichförmiger Perioden, z.B. auf der Autobahn, wird über die normalen Handy-Funktionen das Display dunkel geschaltet. In definierten Abständen vor anstehenden Richtungsänderungen, wird dann jeweils wieder “hell” geschaltet, sodass man eigentlich auch ohne Ansagen immer weiß, wann Aufmerksamkeit angesagt ist. Mir fehlen zur Beurteilung der Qualität der Ansagen und Texte natürlich die Vergleichsmöglichkeiten, aber grundsätzlich empfand ich die Verständlichkeit und Betonung als sehr gut. Aufgrund einer Reise bin ich Anfang Dezember in einem Mercedes C220 Mietwagen mit eingebautem Navigationsgerät mitgefahren. Hier empfand ich einige Ansagen als etwas abgehackt. Grundsätzliches Problem der “Handy”-Navigation ist die mangelnde Lautstärke. Die Ansagen erfolgen über den Handy-Lautsprecher. Wenn man nebenbei noch Musik hört, versteht man fast nichts mehr. Da ich kürzlich das Original-Volvo Autoradio gegen ein Model von Sony ausgetauscht habe, hoffe ich, das sich hier noch ein Besserung ergibt. Entweder wird die Nav4All Software noch weiter entwickelt, sodass Ansagen auch über Bluetooth an das Autoradio weitergegeben werden können oder ich stellen eine Verbindung von SE M600i Fastport Connector zu Radio Aux-Eingang her.

Besonders positiv haben mich die Warnungen bei überhöhter Geschwindigkeit bei der Nav4All Lösung überrascht. Ein Kollege, der ein Medion Navigationsgerät von Aldi erworben hatte, berichtete, das dieses Gerät diese Funktion z.B. nicht bietet. Auch beim eingebauten System im Leihwagen schien diese Funktion nicht vorhanden zu sein.

Um sich wirklich mit der Anwendung vertraut zu machen, ist es günstig, wenn man mit den Handy eine Verbindung ins Internet aufbauen kann, ohne den Provider bemühen zu müssen. Das geht besonders einfach, wenn das Handy das Bluetooth PAN Profil beherrscht. Damit kann man dann seinen Heim-PC als Gateway ins Internet nutzen. Für Gentoo Linux habe ich meine Bemühungen hier niedergeschrieben. Für Debian Linux ist in dem Artikel ein Link enthalten. Für Windows findet man eine entsprechende Anleitung auf SE World im Forum. Wenn man unter Linux in einem Terminal ein watch -n /sbin/ifconfig -a startet, kann man sich sehr gut einen Eindruck über das anfallende Datenvolumen machen.

Update: Als ich am ersten Abend meiner Versuche mit Nav4all die Verbindung über das Bluetooth PAN Netzwerk und meinen PC nicht direkt hinbekommen habe, bin ich dann ungeduldig geworden und habe die Applikation doch direkt über das Provider-Internet installiert. Insgesamt sind für Installation 2030Kb (=0,41€) aufgelaufen. Für den eigentlichen Reisetag sind 140Kb an Navigationsdaten aufgelaufen. Einzelne Neuberechnungen der Routen sind zum Teil mit 0,00€ aufgeführt, sodass sich aus der Rückrechnung der insgesamt angefallenen Datenkosten im November 0,03€ für heruntergeladenen Routeninformationen ergeben.

MGmaps

Als zweiter Applikation für den Hamburg Trip habe ich [Mobile GMaps] auf dem Handy installiert. MGMaps ist eine weitere “Navigations”-Applikation. Ursprünglich als Front-End für Google Maps gedacht, arbeitet die Anwendung jetzt mit dem Karten Material von Yahoo! Maps, Windows Live Local (MSN Virtual Earth), Ask.com und weiteren zusammen. MGMaps ist primär eine reine Online-Anwendung und arbeite praktisch genauso wie Google Maps.

MGMaps kann aber auch mit zwischengespeicherten Daten arbeiten, die man sich vorher auf dem PC heruntergeladen und dann auf den Speicher oder die Speicherkarte des mobilen Telefons herunter geladen hat. Mit den hier aufgelisteten Applikation wird mit dem Map Creation Tool zunächst eine .mapDatei erzeugt. Diese Datei werten dann die beiden Programme MapTileFE und Map Tile Cacher aus, laden dann die entsprechenden Kartenabschnitte herunter und legen sie dann in einem Verzeichnis ab. Dies Verzeichnis wird dann auf das Telefon transferiert. Das Verzeichnis muss MGMaps im letzten Schritt noch bekannt gemacht werden. Auf dem SE M600i habe ich das Verzeichnis mit den Kartendaten in das Verzeichnis “Other” auf dem Memory-Stick abgelegt. Als es sich zunächst mit Wurzel-Verzeichnis der Karte befand, war ich nicht in der Lage, dies Verzeichnis innerhalb von MGMaps auszuwählen.

MGMaps arbeitet auch wunderbar mit dem Holux Bluetooth GPS-Empfänger zusammen. Mit dem im Vorfeld herunter geladenen Kartenmaterial kannten wir jederzeit unsere Position, als wir dann durch Hamburg spaziert sind.

Nav4All und MGMaps sind wirklich zwei sehr empfehlenswerte Anwendungen für das Handy.

Update: In der GSM Arena gibt es eine Übersicht von Navigationslösungen für das Handy.

On the old server with MySQL 4.x and WordPress 2.0.x I was using this combination already with UTF-8 encoding although WordPress 2.0.x is originally intended for ISO-8859-1 only. However no encoding changes took place on the way from the database to the browser, so this was actually no problem.

On the new server the database base (now MySQL 5.0.x) is operating with the default encoding of ISO-8859-1. Now the UTF-8 data within the tables was converted to ISO-8859-1 character, which resulted funny looking articles with German umlaut characters. After having finally found this article and having set DB_CHARSET and DB_COLLATE in the wp-config.php files, everything is good again.

Changing versions of multiple components at the same time has always the increased risk, that something get screwed up along the way.