Sun Type 6 Keyboard

I’ve written about my issues with my SUN Type6 keyboard in the company. I’ve finally found a 100% satisfactory solution. In the end, all fiddling with xmodmap and setxkbmap didn’t really help. To really fix my issues I needed to edit the file /usr/share/X11/xkb/keycodes/evdev to shuffle some keycodes around.

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).

X.Org 1.5.x, evdev and HAL

The move to X.Org server 1.5.x was not quite the smooth ride I expected it to be. It took me the better part of a Saturday afternoon to get everything in working order again. Some time ago (actually already 2 month have gone by) I used the opportunity to do this, while fiddling with Ubuntu 8.10 on an externally connected USB drive. I compiled the X-server in a chroot environment on my standard os partition.

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.

Medion PNA E4430 (MD 96960) von Aldi

Am Donnerstag, dem 26. Juni 2008, war bei Aldi mal wieder ein Navigationsgerät im Angebot, diesmal ein Medion E4430 (MD96960) für 179€. Bisher hatte ich noch nicht die wirkliche Notwendigkeit gesehen, im Hinblick auf die Reisen, die wir normalerweise unternehmen, ein eigenes Gerät zu erwerben (sprich: zu geizig) und habe stattdessen bei der letzten Gelegenheit mit der Nav4all Offboard-Lösung experimentiert. Nav4all hat eigentlich auch vorzüglich funktioniert, aber da wir dieses Jahr wieder mal nach Dänemark in den Urlaub wollen, fällt im Ausland Handy-Navigation flach, weil bei Simyo im Ausland kein Internet auf dem Handy zur Verfügung steht.

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.

Lightzone for Linux

Great news for Linux and digital photography enthusiasts. Apparently since yesterday “Lightzone for Linux” is available as an official product with the same functionality as the Windows and Mac Versions. Lightcrafts released a couple of betas for Linux, but no “real” product. They are even offering an introductory discount. With this discount the purchase of Lightzone will set me back about 100 Euro.

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

Back to 32bit Linux?

In the beginning of this year I build myself a new PC with Intel E6750 processor, Gigabyte P35DS3R motherboard, Samsung HD501LJ 500Gb disk (370Gb with EXT3 for Linux), Nvidia 8600GT graphics card and 4Gb of memory. I decided to install a 64bit Gentoo Linux, currently with kernel 2.6.24-r3. On first impression the system seems to be quite quick. The software compiled very fast. The first evidence, that something was not quite right, were during playbacks of mpeg2 files with VLC, where there were frequent sound drops. I didn’t experience these drops with my old AMD XP 2800+.

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.

Gentoo with 64bit kernel

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).

Gentoo 64bit with 4Gb main memory
Gentoo 64bit with CFG scheduler

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

Gentoo 64bit with XFS-fs in an image
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

Gentoo 64bit with EXT3-fs in an image
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

With Knoppix 5.3 and 32bit kernel

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.