T60: Die Tastatur, die Henne und das Ei

Seit einigen Wochen habe ich einen neuen Laptop...

Naja, ein Gebrauchtgerät - Lenovo T60 - erworben beim Gebraucht-Laptop-Händler meines Vertrauens, bei dem ich über die Jahre schon einige Geräte der jeweils vorletzten Generation erworben habe.

Wie bei früheren Laptops, so hatte auch dieser eine ausländische Tastatur. Der Laptop kam mit Etiketten zum Überkleben der Tasten. Das war bei früheren Käufen auch so gewesen und die Etiketten halten immer noch.

Unterdessen läuft Ubuntu Karmic mit Gnome auf dem Rechner. Die diversen Funktionstasten werden unterstützt (laut, leise, heller, dunker) und auch Blender ist dank der Kraft der zwei Kerne halbwegs flott.

Etwas gestutzt hatte ich dann gestern, als ich auf der Kommandozeile eine etwas längere Ausgabe mit | less seitenweise anzeigen wollte. Nirgendwo war der senkrechts Strich zu finden.

Sollten die Aufkleber doch nicht so vollständig gewesen sein? Nachdem ich alle Tasten mit gedrückter Alt-Gr-Taste durchprobiert hatte stand fest: kein senkrechter Strich. Nun gut, dann eben eine Umleitung in eine Datei - aber auch das Größerzeichen war nirgends zu finden.

Fehlt also eine Taste?

Die Antwort ist: ja. Nach ein wenig googlen fand ich auf Notebookcheck ein Bild des Laptops mit aufgeklappter Tastatur. Die dort gezeigte Tastatur (oben rechts) hat im Gegensatz zu meiner eine schmalere linke Shift-Taste. In dem freiwerdenden Zwischenraum liegt normalerweise: < > |

Wahrscheinlich hat Sprache, für die die Tastatur eigentlich ausgelegt ist, weniger Sonderzeichen, braucht weniger Tasten und das < > befinden sich irgendwo unter den Tasten Ä Ö oder Ü.


Was also tun? Ohne "größer" und "kleiner" ist das Programmieren recht umständlich. Und wie häufig man auf der Kommandoebene die Pipe benutzt merkt man erst dann, wenn es nicht mehr geht...

Umdefinieren der Tastatur mit Xmodmap

Im Ubuntu-Wiki gibt es hierzu einen ausführlichen Eintrag.

Erster Schritt: Auslesen der aktuellen Zuweisung.

Hierzu muss im Home-Verzeichnis der Befehl

xmodmap -pke > .Xmodmap

eingegeben werden, was bei fehlendem ">" ein echtes Henne- und Ei-Problem ist. (Ich habe schließlich auf einem anderen Rechner (mit voller Tastatur) ein einzeiliges Skript geschrieben und auf den Laptop kopiert).

Sucht man in .Xmodmap nach "greater", so findet man zwar:

keycode 94 = less greater less greater bar brokenbar bar

Versucht man aber - nach Aufruf des Programms xev - die Taste mit dem Keycode 94 zu finden, so wird man nicht fündig. Ich habe mich schließlich für die Tasten "Blättern" (links und rechts über "Cursor links" und "Cursor rechts", Keycode 166 bzw. 167) entschieden und die Belegung dort wie folgt geändert:

keycode 166 = less bar XF86Back NoSymbol XF86Back

keycode 167 = greater NoSymbol XF86Forward NoSymbol XF86Forward

Nachdem Aufruf

xmodmap .Xmodmap

sind die fehlenden Zeichen nun zugänglich.

Spezielle Behandlung von ~/.Xmodmap

Nach einer einmaligen Nachfrage beim nächsten Einloggen wird die geänderte Tastaturbelegung unter X dauerhaft aktiv.

Hugin - Probleme unter Windows

Hugin ist ein Open-Source-Projekt dessen Software u.a. dazu eingesetzt werden kann mehrere Einzelbilder zu einem Panorama zu kombinieren, ein Vorgang, der als "Stiching" bezeichnet wird.

Damit die Aufnahmen nahtlos ineinander übergehen müssen sog. Kontrollpunkte gesetzt werden. Der Kontrollpunkt in Bild A und der zugehörige Kontrollpunkt in Bild B bezeichnen den gleichen Ort in der realen Welt.

Man kann diese Kontrollpunkte von Hand setzen, aber auch dafür gibt es mittlerweile Hilfsprogramme. Ein bei Hugin-Usern sehr beliebtes (weil schnelles) Programm ist autopano-sift-c. Es sucht in den Bildern nach markanten Punkten und versucht diese zuzuordnen.

Im nächsten Schritt beginnt Hugin anhand dieser Daten die Bilder passend zu verzerren, zu verschieben und zu überblenden.

Die Probleme


Hugin ist mittlerweile auf diverse Plattformen portiert - so auch Windows - von wo mich der Hilferuf erreichte, der zu diesem Posting führte. Es waren mehrere Probleme aufgetreten, die das Programm unbrauchbar machten.

Hugin wird bei SourceForge gehostet. Die zurzeit (März 2010) dort verfügbare Windows-Version ist schon 2 Monate alt.

Unterdessen sind compilierte neuere Builds aus dem Hugin Subversion Repository aus anderen Quellen verfügbar und mein Bekannter hatte das neuste Build installiert (als User von Blender 2.5 kann ich das nachfühlen).
Diese Builds führen jedoch beim Laden der von ihm verwendeten TIFF-Dateien zu einem "TIFF library error". Ein Downgrade auf die ältere SourceForge-Version beseitigte das Problem.

Auch beim Suchen der Kontrollpunkte ist die neuere Variante (Autopano-SIFT-C version 2.5.2 23July2009) nicht die bessere.

Das Fehlerbild hier: Hugin meldet, dass keine Kontrollpunkte gefunden wurden.

Ruft man das Programm über die Kommandozeile auf, erkennt man, dass zwar einige Punkte gefunden werden (einige Hundert), normal sind jedoch 1000 und mehr. So verwundert es nicht, dass beim Abgleich, welche markanten Punkte aus Bild A zu denen in Bild B passen könnten, zum Schluß keiner übrig bleibt.

Abhilfe schafft hier, wie von Bart van Andel in einem Google-Groups-Thread beschrieben, die ältere Version 2.5.1 (Download Link siehe erwähnter Thread). Das Einbinden der neuen Version erfolgt über "Datei - Einstellungen - Kontrollpunkt-Detektoren".

Fazit

Sollte eines der oben erwähnten Probleme auftreten, so scheint zurzeit die folgende Kombination am stabilsten zu laufen:

Hugin_2009.4 von SourceForge und Autopano-SIFT-C 2.5.1.

Blender 2.5 alpha 1 verfügbar

Seit heute ist Blender 2.5 alpha 1 verfügbar.

Dieses offizielle Release läuft auch unter Ubuntu Hardy - der (noch) aktuellen LTS-Version von Ubuntu.

Bei den aktuelleren Blender Builds auf GraphicAll.org war das seit dem Übergang von Alpha 0 auf Alpha 1 leider nicht mehr der Fall.

Python: cStringIO vs. StringIO

If a function expects a file handle as an input parameter, but the data you want to process is stored in a string variable, you could store its content in a temporary file on disk, then open that file and use its file handle for the above mentioned function.

A nicer way to do this is the python function StringIO in the StringIO library. It takes the string as an argument and returns a file handle, from which the function can read(). The conversion happens in memory, i.e. no tedious creation of temporary files.

Depending on how often you need this functionality and how large the data is, the StringIO.StringIO - which is programmed purely in Python - may be too slow.

The library cStringIO offers a function with the same name with the same functionality carried out by a faster C-implementation. This function should be a drop-in replacement for the Python version.

However, since more and more strings are stored in unicode this function has an unexpected side effect. This side effect is detailed in the library description, if you look close enough.

cStringIO.StringIO does not return the original encoded text, but the "representation of the Unicode string", which may differ from machine to machine:

>>>import StringIO
>>> a = StringIO.StringIO(u"test")
>>> a.read()
u'test'

>>>import cStringIO
>>> a = cStringIO.StringIO(u"test")
>>> a.read()
't\x00\x00\x00e\x00\x00\x00s\x00\x00\x00t\x00\x00\x00'

A patch to fix this was proposed but rejected due to backwards compatibility.

So be aware...

wxPython-Versionen auswählen

Wenn mehrere wxPython-Versionen gleichzeitig auf einem System installiert sind, so lädt ein einfaches

import wx

natürlich immer die Version, mit der man gerade nicht arbeiten will.

import wxversion
wxversion.select('2.8')
import wx

Die Version des gerade geladenen Moduls erhält man mit:

print wx.__version__

Changing USB device permissions in Ubuntu Karmic

If you plug an USB device into a Linux box that uses a current distro, udev dynamically creates an entry in the /dev directory. You can list all currently available USB units with the lsusb command:

$ lsusb

Bus 002 Device 003: ID 03eb:6125 Atmel Corp. 

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The only "real" device here is my XAiOX GPS logger (first entry). The output shows that it has the vendor id (hex) 03eb, the product id (hex) 6125.

The device file created by udev is: /dev/bus/usb/002/003
(Yes, these are the bus and device numbers shown in the lsusb output).

The default permissions are rather restrictive:

$ ls -l /dev/bus/usb/002

insgesamt 0

crw-rw-r-- 1 root root 189, 128 2009-12-23 22:14 001

crw-rw-r-- 1 root root 189, 128 2009-12-23 22:19 003

Only root can read and write to the USB device. Anybody else only has read access.

In order to retrieve the stored GPS info from my GPS logger (e.g. by using itrackutil), I have to instruct the device to send the data. In order to send this command I need the write privileges.

I could start itrackutil as root, but from a security standpoint that is not what I want.

This problem usually arises only, if the USB device is not (yet) managed by the system, because part of that managing process is... changing the permissions.

The solution I'm suggesting here works with Ubuntu Karmic.

The first step is to create a group named usbusers (or any other name), then make yourself member of that group and instruct udev to set the device group id to usbusers and set the permissions accordingly.

On the command line, creating a group and adding the user (e.g. mike) is quite simple:

sudo groupadd usbusers

sudo adduser mike usbusers

If you pefer the Gnome GUI, you find the appropriate program under "System - Administration - User and groups":

After unlocking the panel ("Click to make changes"), click onto "Manage Groups".

"Add Group".

Make enter "usbusers" as group name, make sure that the group id suggested by the system is not zero. It's usually in the 1000+ range, enable the "Group Members" and click "Ok".

As a last step you have to create a new udev rule:

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664", GROUP="usbusers"

Save it under the following name: /etc/udev/rules.d/45-xaiox.rules

Then reboot.

Two remarks regarding the filename:

• in order to be executed, the filename must end with .rules (all other files are ignored)
• the 45 ensures that the file is executed before the corresponding "old" rule found in /lib/udev/rules.d/50-udev-default.rules

If you now plug-in your usb device, the permissions look like this:

$ ls -l /dev/bus/usb/002/total 0crw-rw-r-- 1 root usbusers 189, 128 2009-12-25 20:20 001crw-rw-r-- 1 root usbusers 189, 133 2009-12-25 22:22 006

And being a member of usbusers, you have read and write access.

Blender 2.5 alpha, slow screen update

Now that I got Blender 2.5 alpha 0 running on my old laptop, I noticed that when rotating what must be the most deleted cube in the 3D world, the refresh rate was very slow. An update rate of 2 or 3 times per second makes the program unusable.

Granted, the laptop is not very fast, but in the old version of Blender (2.49a) the cube followed the mouse movement without any visible delay.

Having seen Blender using OpenGL without hardware acceleration before, I tried pressing one of the OpenGL buttons down in the "header" of the 3D window:

This produced the error: "Failed to create OpenGL offscreen buffer".

Something was wrong with the use of OpenGL.

User teeth in the developer IRC channel #blendercoders on freenet.org, suggested to change the user preferences from "Triple Buffer" to "Overlap".

You can display these settings using "File - User Preferences" or Ctrl-Alt-U. Then select "System" and look for the "Window draw method".

Don't forget to "Save as default".

It worked here. If you have the same problem, it's worth a try.