Tag Archives: HCI

Logitech-HID mit Debian Sid

Nutzer der Unstable-Variante von Debian (auch als Debian Sid bekannt) bekommen ja bekanntlich regelmäßig Gratisabenteuer aus dem Bereich der Systemadimistration geschenkt; sozusagen ein Quest-Abo.

Problem des Tages: Einen Systemstart nach dem letzten Update funktionierten Bluetooth-Tastatur und -Maus von Logitech nicht mehr, in meinem Fall konkret das Dinovo-Set.

Ich habe häufiger Ärger mit Logitech unter Linux, meistens ließ sich das aber mit einem Reset des Bluetooth-Dongles1 beheben. Dieses Mal nicht, der Fehler war persistent.
dmesg, logs und Modulliste waren soweit korrekt, es war alles da, was für die Geräte gebraucht würde und es wurde laut lsusb auch alles erkannt. Nur funktionierte einfach nichts. $SUCHMASCHINE lieferte dafür auch keine weiteren Ergebnisse.

Letztendlich habe ich das Problem in den udev-Regeln2, speziell der Datei 70-hid2hci.rules gefunden. Dort steht in Zeile 15:

Ein kurzer Blick auf die Manpage zeigt, dass der Aufruf nicht korrekt ist. Ich habe die Zeile so abgeändert:

Seit dem funktionieren Tastatur und Maus wieder einwandfrei.

Die Regel deckt einen großen Bereich von Logitech-Produkten ab, das Problem tritt also wohl auch dort auf. Debian-Bugreport kommt dann später noch.

  1. Abziehen und wieder dranstecken. ;) []
  2. zu finden unter /lib/udev/rules.d/ []

Opera stellt fest

Habe gerade Opera Update auf 10.10 eingespielt und bekomme gleich als erstes folgende Meldung:

Opera hat festgestellt, dass KDE läuft.

Einige von Operas Tastaturkürzel (wie Strg+F4) könnten nicht funktionieren, da KDE diese reserviert hat.

Sie können die KDE Tastenkürzel im KDE Kontrollzentrum ändern.

WTF? Ich werde doch nicht mein ganzes System umstellen, nur weil ein einziger proprietärer Browser da gern seine eigenen Tastenkürzel hätte. Zumal ich bei Opera sowieso immer das Problem habe, dass ich mit Tastenkürzeln, die ich aus anderen Programmen kenne, dort ins Leere laufe oder völlig unerwartete Sachen auslöse. Wieso schlägt Opera nicht vor, wie man seine eigenen Tastaturkürzel ändert? Frechheit! Naja, bleibt es halt weiterhin nur der billige Pornobrowser

Ausgesperrt bei Nacht

Ursprünglich hatte ich angefangen, diesen Beitrag in meinem noch recht neuen privaten Blog zu schreiben (der Tux hat übrigens auch eins), im Laufe des Schreibens wurde das dann aber doch zu technisch und passt eher hier her.

Warum also ausgesperrt? Es begann vor einigen Wochen, als mein bis dato stets zuverlässiges Notebook Samsung X05 plötzlich ab und zu stehen blieb, also einfror, sprich im laufenden Betrieb plötzlich nichts mehr ging. Mauszeiger ging nicht mehr, Bildschirminhalt änderte sich nicht mehr und sämtliche Tastatureingaben waren wirkungslos. Da half nur harter Reset und fortan Notebook nicht mehr bewegen, was natürlich die erwünschte Mobilität ad absurdum führt.

Unterdessen sah ich mich nach einem Ersatz um, der noch etwas leichter und kleiner als das 14″-Gerät (Masse etwa 2.1kg) sein sollte. Mittlerweile bestellt ist das Samsung NC10 in schwarz mit UMTS-Option. Ich hoffe, dass es ebenso zuverlässig sein wird, die technischen Daten und Testberichte stimmen da optimistisch. (Meine Erfahrungen damit, speziell im Hinblick auf Linux, werden folgen.)

Wenige Stunden nach der Bestellung dachte ich mir dann, dass ich das BIOS-Passwort, was beim alten Laptop stets abgefragt wurde, mal abschalten könne. Das wiederholte Eingeben bei den ganzen hardwarebedingten Reboots war etwas nervig. Gesagt getan: im BIOS-Setup dann keine Möglichkeit das abzuschalten, nur es zu ändern. Im Dialog zum Ändern hab ich also einfach zweimal Enter gedrückt und dann war ich ausgesperrt. Seitdem wird weder zwar immernoch das Passwort abgefragt, aber weder das alte Passwort noch einfach »Enter« drücken hilft. Es endet stets mit der Meldung »System disabled«, wohlgemerkt noch vor dem eigentlichen Booten.

Zunächst sei dazu angemerkt, dass ich das für einen schweren Bug in der BIOS-Software halte, weil der Nutzer an keiner Stelle darauf hingewiesen wird, dass sich der Rechner bei dieser Art Eingaben so verhält. Oder anders gesagt: das Ding hat sich hier an meinen durch langjährige Erfahrung geprägten Erwartungen vorbei verhalten. :-/

Die offensichtliche Lösung im Weltnetz ein passendes Master-Passwort zu finden, war zum Scheitern verurteilt und so wendete ich mich an den Support von Samsung. Ich erwähnte wann und wo ich das Gerät gekauft hatte und zudem, dass ich wegen räumlicher Trennung derzeit nicht in der Lage bin, an den Kassenzettel zu kommen. Interessiert Samsung aber nicht:

Da das BIOS-Passwort eine sicherheitsrelevante Einrichtung darstellt, benötigen wir aus rechtlichen Gründen eine Legitimation von Ihnen, zum Beispiel in Form eines Kaufbelegs, bevor wir Ihnen mit der Entsperrung eines BIOS-Passworts behilflich sein können.

Ok, war zu erwarten, wirft aber dennoch die Frage auf, was ich machen soll, wenn ich das Gerät beispielsweise gebraucht ohne Original-Kassenbon oder Quittung gekauft hätte? Wie soll ich da mein Eigentum nachweisen? Fotos mit mir und dem Gerät beim Verkäufer? Router-Logfiles mit der MAC-Adresse? Ich meine, ich verstehe ja, dass die das nicht jedem potentiellen Langfinger erzählen wollen, aber dann sollen sie doch bitte das BIOS-Setup so programmieren, dass man sich nicht versehentlich aussperren kann. :-(

Nachtrag: Mittlerweile habe ich den Kassenbon eingescannt und an Samsung geschickt. Heute bekam ich den Rückruf und gemeinsam mit dem Support-Menschen, konnte das Problem näher eingegrenzt werden. Nach dreimaliger Fehleingabe des Passworts zeigt das Notebook einen längeren String an, den man dem Support-Menschen vorliest. Der wiederum erzählte mir dann das aktuelle Passwort, das mir dann seltsam bekannt vorkam. Es stellte sich heraus, dass es genau zwei Passwörter gibt: ein System-Passwort und ein User-Passwort. Ersteres benötigt man, um ins BIOS-Setup zu gelangen, letzteres nur um den Rechner zu starten. Das Problem war nun, dass ich vergessen hatte, dass ich unterschiedliche Passwörter vergeben hatte. Ich wäre also noch mit dem eigentlich bekannten System-Passwort ins BIOS-Setup gekommen. Dort stellte ich dann fest, dass die zuvor als buggy gebrandmarkte Methode das Passwort wieder zu entfernen doch korrekt funktionierte. Ich konnte also beide Passwörter auf diese Weise wieder »clear« bekommen. Das einzige Problem war nun, dass anscheinend das System-Passwort beim Boot abgefragt wurde, wenn das User-Passwort nicht gesetzt war. Das muss man dann aber auch wissen. ;-)

CLI siegt

Spontane Erkenntnis: Ich nutze lieber den Kommandozeilenclient als die Shell-Extension im Kontextmenü – jedenfalls wenn es um Subversion geht. Gerade Routineaufgaben wir update und commit gehen damit einfach schneller.

Mögliche Erklärung: In der KDE kommt man aus dem Dateimanager per F4 in ein Konsolenfenster mit dem aktuellen Verzeichnis. Dort muss ich dann nur noch svn up eingeben, mit das Ergebnis anschauen und die Konsole mit Strg+D wieder schließen. Das geht wesentlich schneller, als mit der Maus im Kontextmenü die entsprechende Option zu suchen.

Die HCI-Community spricht hierbei von habit, also der Gewohnheit beziehungsweise Routine. Während man bei der Mausbedienung zuerst den Mauszeiger suchen muss, um ihn dann auf die richtige Position im Dateimanager und im Kontextmenü zu navigieren, ist die Position der Tasten fest, die Tastaturbedienung bedarf also wesentlich weniger Planung und fördert daher eher ein routiniertes Vorgehen. Letztendlich entlastet das das Gehirn und wird deshalb als energiesparende Maßnahme bevorzugt. Aber wer gern Shortcuts benutzt, kennt das ja … 8)

Nachtrag: Da war ich wohl etwas eilig und hab die Abkürzungen nicht erklärt…

CLI = Command Line Interface; eine Form von Kommandozeile, entweder auf der Konsole oder in ein Programm eingebettet.

HCI = Human-Computer-Interaction oder Human-Computer-Interface, also die Schnittstelle beziehungsweise Interaktion zwischen Mensch und Computer.