Kubuntu Menü mit Windows Taste öffnen

Das war bisher Standard unter Kubuntu. Du drückst die Windows-Taste der Tastatur und schön öffnet sich das Menü. Eine Tatsache, die mir als langjährigem Windowsnutzer sehr wichtig ist und mein Arbeitstempo beschleunigt, da ich den unsäglichen Weg zur Mouse nicht gehen muss, sondern gleich mein gewünschtes Programm via Keyboardeingabe suche.

Aber was ist, wenn man versehentlich mal die Taskleiste (bzw. das Plasmoid) entfernt und neu hinzufügt? Dann geht’s nicht mehr, und das ist blöd.

Doch Abhilfe ist leicht gefunden: Rechtsklick auf das KDE-Symbol -> Anwendungs-Starter einrichten -> Kurzbefehle -> ALT-F1 eingeben und quittieren, dass die vormals belegte Funktion (zum Aufrufen des Anwendungs-Starters, ein wenig Humor muss ja sein -.-!) neu eingerichtet werden soll. Und et voila öffnet die Windows-Taste wieder das Menü.

Doch wo steckt da der Sinn? Dieser Beitrag hält eine kurze Eklärung bereit.

Tiptoi-Stift hört abrupt mitten im Buch auf zu spielen

Genau das ist mir widerfahren! Mein Sohnemann spielt TipToi und auf einmal hört der Stift auf, jedwede Art von Geräusch von sich zu geben. Defekter Lautsprecher war mein Gedanke, doch mit eingestecktem Kopfhörer war ebenso nichts mehr zu hören. Gar nichts? Naja, das einstecken selbst hat zu einem kurzen Geräusch geführt (Spannung auf den Ohrhörern), also kann es weder ein defekter Lautsprecher noch die defekte Klinke sein.
Dann fiel mir auf, dass das Abspielen von Liedern und Hörbüchern interessanterweise funktionierte – wenn auch ohne Bestätigungsansage durch den Stift. Also doch nicht defekt – puh!

Was nun? Erstmal alles versucht: im TipToi-Manager repariert (nix geschehen) und den Wunsch die Firmware zu aktualisieren. Leider Fehlanzeige, war ja schon die aktuellste. Also über die Ravensburger-Seite die manuelle Firmware geflasht und siehe da: ich habe wieder Sprachansagen.

Aber was ist das? Ich kann zwar den Stift wieder benutzen, doch die Audiodateien können irgendwie nicht erkannt werden, der Stift ist also nutzlos! („Bitte lade dir erst die Audiodatei zu diesem Produkt“ oder so ähnlich …) Auch die Lieder konnten nun nicht mehr abgespielt werden. Also Stift formatiert (Linux, Fat32) und neu versucht, erfolglos. Gleiches Prozedere unter Windows, gleiches Ergebnis. Fehlerreperatur über PartitionManager, GParted oder die Windows Datenträgerreperatur – erfolglos. Ich wollte das Ding schon wegwerfen.

ABER DANN =) Ich habe den Stift anschließend von allen vorhandenen Partitionen befreit und über ein beherztes

sudo fsck.vfat -r -w -a -v /dev/sdb

(ohne Partitionsauswahl, also nicht /dev/sdb1 sondern die Wurzel!) überprüft mit dem Ergebnis, dass da sau viele korrumpierte Einträge vorhanden waren, die ich nun reparieren konnte. Das Reparieren über fsck.fat bzw. an /dev/sdb1 vorher sind erfolglos und ohne Fehlermeldung abgebrochen.

Nun noch eine FAT32-Partition ins Wurzelverzeichnis schieben, sodass ich wieder auf den Stift schreiben kann. Dafür bemüht sich kinderleicht ein

sudo mkfs.vfat -F 32 /dev/sdb

und das Dateisystem steht. Stift vom Rechner trennen, ein- und nach Bereitschaft ausschalten (wahlweise mit den Standarddateien befüllen, wie in diesem Beitrag von mir aus dem Jahr 2017 geschildert) und anschließend mit Inhalten befüllen. Fertig. Und wieder 40,-€ gespart und sinnvolle Umweltressourcen geschont.

W-Lan Webcam als lokale Webcam im Browser und darüber hinaus nutzbar machen

Bin seit einigen Monaten im Besitz einer Hikam S6 W-Lan-Überwachungskamera. Für diesen Zweck nutze ich sie jedoch eigentlich gar nicht; sie liegt nur herum. In Zeiten von häuslicher Lernzeit, dem sächsischen Homeschooling, wäre es jedoch ganz praktisch, die relativ gute Qualität der Kamera auch lokal nutzbar zu machen, um beispielsweise an Videokonferenzen teilhaben zu können.

Und das geht unter Linux tatsächlich ziemlich einfach, wenn man weiß wie. Hinweis auf alles gab mir dieser Artikel.

Zunächst installiert man in der einschlägigen Ubuntu-Distribution das Video4Linux2 Loopback Device und lädt den Treiber mittels

sudo apt install v4l2loopback-dkms
sudo modprobe v4l2loopback

Hiernach bedarf es lediglich noch des Wissens um den RTSP-Stream (das Video/Audio-Signal der Webcam). Dafür bedarf es des Wissens um die IP der Kamera (in meinem Falle die 192.168.X.10), die sich beispielsweise über den Router oder das Handbuch der Kamera in der Ausgangskonfiguration finden lässt. Sodann kann ich mit folgendem Befehl das Bild via W-Lan als lokale Webcam meines Rechners streamen und wiederum im Browser, Skype oder beliebiger anderer Software als Dummy auswählen (die passende Adresse noch einsetzen):

ffmpeg -re -i  rtsp://192.168.X.10:554/stream=0 -map 0:v -vf format=yuv420p -f v4l2 /dev/video0

Und weil’s so schön ist, habe ich mir das ganze in Form eines YAD-Skripts automatisiert, sodass ich lediglich einen Knopf drücken, das Nutzerpasswort eingeben und mich zurücklehnen muss. Dieses sieht bei mir wie folgt aus:

#!/bin/bash
#
# starting local webcam dummy via v4l2loopback as an rtsp stream
Encoding=UTF-8
TITLE=Webcam
VERSION=0.02
ICON=/usr/share/icons/Adwaita/64x64/apps/preferences-desktop-accessibility-symbolic.symbolic.png
# run webcamscript
yad --title="Webcamsteuerung" --text="Webcam …?" --button="Einschalten" --button="Ausschalten" --button="Programm Beenden"
#Returnwert speichern
ret=$?
#Auswerten des Returnwertes
if [ $ret = 0 ] #Wenn der Benutzer auf Einschalten drückt,
then            #dann führe folgenden Befehl aus
    eingabe="$(yad --entry --hide-text --button="Passwort" --title="Passwort" --text="Bitte gib dein Passwort ein:")"
    /usr/bin/sudo -u Nutzer -p $eingabe modprobe v4l2loopback | ffmpeg -re -i  rtsp://192.168.X.10:554/stream=0 -map 0:v -vf format=yuv420p -f v4l2 /dev/video0
fi
if [ $ret = 1 ] #Wenn der Benutzer auf Ausschalten drückt,
then
    eingabe="$(yad --entry --hide-text --button="Passwort" --title="Passwort" --text="Bitte gib dein Passwort ein:")"
    /usr/bin/sudo -u Nutzer -p $eingabe killall ffmpeg
else            #Ansonsten führe diesen Befehl aus
 exit 1         #Befehl (hier exit 1 für beenden)
fi

Nicht vergessen, auch den Nutzernamen und die IP in den beiden if-Schleifen anzupassen.

Viel Spaß =)

Citrix Receiver mit Fehler 1000119

Die Citrix Workspace App ist für Ubuntu mittlerweile eine schöne runde Sache: lässt sich leicht installieren, läuft out of the box und gibt eine sehr angenehme Performance. Das Schmankerl – meine Multimediageräte wie Drucker, Headsets etc. werden auch serverseitig erkannt und durchgereicht, sodass ich auch aus der Ferne an Webkonferenzen teilnehmen kann. Gut gemacht und das große Plus gegenüber der sonst schon sehr leistungsfähigen Browservariante.

Aber was tun, wenn die App nicht verbindet, sondern den Versuch mit einem Fehler 1000119 quittiert? Irgendwas mit Zertifikaten, wie das Citrix Support Center behauptet. Doch nützt deren Anleitung? Leider nein.

Dabei ist das Problem recht leicht zu beheben, denn grundlegend vertraut die Workspace App lediglich ihren eigenen Zertifikaten, nicht jedoch denen des Systems. Und hier hilft folgende Anleitung:

sudo ln -s /etc/ssl/certs/* /opt/Citrix/ICAClient/keystore/cacerts

Dieser Befehl führt dazu, dass ich mit Systemadministratorrechten über einen symbolischen Link (ln -s) aus dem Zertifikatsverzeichnis von Ubuntu und Derivaten (/etc/ssl/certs) alle Einträge (*) in das Citrix-eigene Verzeichnis übertrage.

Ich habe dann noch folgenden Schritt durchgeführt, um ganz sicher gehen zu können, dass Citrix diese Änderungen auch mitbekommt:

sudo /opt/Citrix/ICAClient/util/ctx_rehash 

Dies führt dazu, dass erneut mit Systemadministratorrechten die neuen Einträge in die Citrix-eigene Datenbank aufgenommen werden.

Et voila – läuft =)

Privacy Policy Settings

Datenschutz DSGVO
Klick