Raspberry Pi: Probleme mit USB-Tastatur und LAN

Wer seinen Raspberry grundsätzlich eingerichtet hat, will vermutlich bald in’s Internet. Bei mir stellte sich gerade das Problem, dass meine Tastatur nicht mehr geht, wenn ich LAN einstöpsel… keine Ahnung, woran das liegt, irgendwelche Vorschläge? Vielleicht zieht sie zu viel Strom oder so.

Aber wie dem auch sei: LAN-Kabel wieder ab. Über “sudo raspi-config” öffne ich den Config-Screen und aktivere den SSH-Server. LAN-Kabel wieder dran, Tastatur ab. Über die Heimnetzwerk-Übersicht meines Alice-Routers (ok, über Umwege geht es auch über’s Terminal) finde ich heraus, dass das Rasperry (Netzwerkname “raspberrypi”) die IP 192.168.1.53 hat. Von meinem Macbook aus rufe ich im Terminal “ssh pi@192.168.1.53” auf (und bestätige beim ersten mal den Fingerprint), und gebe das von mir nicht geänderte Passwort “raspberry” ein. Schon bin ich auf dem System, und kann von hier aus so weitermachen, wie ich es eigentlich über die USB-Tastatur machen wollte.

Stellt sich raus: Das muss ich erst mal gar nicht 🙂 Ein “ping www.google.de” funktioniert direkt. DHCP muss im Router natürlich aktiviert sein, sonst wäre hier manuelle Konfigurationsarbeit nötig. Trotzdem ist es nett zu wissen, dass man so einfach per SSH draufkommt, denn schliesslich will man ja irgendwas machen können im LAN, und ohne Tastatur wird das knifflig. Außerdem muss mein Fernseher nicht mehr eingeschaltet sein, und ich kann auf dem Sofa sitzen^^

wmode transparent: @-Bug

Der altbekannte Bug, kein @-Zeichen eingeben zu können, wenn der wmode auf transparent steht, sollte in Flash-Player 10.1 behoben sein. Ist er nicht. Zumindest nicht in Chrome. Man nutze diesen Workaround:

Wenn wir auf Windows sind (denn nur hier tritt der Bug auf), erlaube das @-Zeichen nicht als regulären Input. Denn in einigen Browsern tritt der Bug nicht auf, und in diesen Browsern wollen wir keine doppelten @-Zeichen 😉 Außerdem verbieten wir q und Q, denn leider leider kann man auf dem KeyboardEvent kein preventDefault() aufrufen. Wir hätten dann “@q”, bzw “@Q”, statt nur “@”.

Stattdessen prüfen wir jedes eingegebene Zeichen mit dem folgenden Listener auf @/q/Q (KeyCode 81 – unter OS X ist der Code ein anderer). Hier ist zu beachten, dass der Cursor nicht am Ende des Textes stehen muss! Und nicht nur das: Es kann auch Text markiert sein, wenn man das @-Zeichen eingibt. Deshalb die etwas aufwendige Bestimmung des Bereiches, der durch @ ersetzt werden muss. Zum Schluss setzten wir den Cursor hinter das frisch eingegebene Zeichen.

Was mich jetzt noch interessieren würde: In dem Ticket ist die Rede von “ALTGR+2” statt “ALTGR+q”; der Autor des Tickets ist Norweger. Damit wird der obige Code nicht funktionieren, denn KeyCode 81 ist das “q” 🙁 Alternativ habe ich die Prüfung

probiert. Das liefert mir auf OS X das erwünschte Ergebnis (“@”), aber auf Windows ist ALTGR+q das “q” und nicht “@”, ich gehe deshalb davon aus, dass ALTGR+2 die “2” ist 🙁 Gibt es keine international gültige Version, nur mittels KeyboardEvent auf die Eingabe von Sonderzeichen zu prüfen??