Schlagwort-Archive: Xorg

ELAN Touchpad/Linux: Rechtsklick mit zwei Fingern einrichten

Touchpads sind an vielen Mobilgeräten verbreitet. Kompakter als eine Maus, genauer als ein Touchscreen. Wenn es darum geht, wie man diese Bedient, verfolgen verschiedene Hersteller jedoch unterschiedliche Konzepte. Meine bisherigen Laptops nutzten dabei folgende Methode: Zum (links)Klicken drückt man das Pad über den Druckpunkt, für einen Rechtsklick selbes spiel, während zwei Finger auf dem Touchpad sind. Ein neueres Modell mit ELAN-Touchpad fällt hier aus der Reihe: Der „normale“ Klick geht zwar auch über den Druckpunkt, für einen Rechtsklick muss man aber in der unteren, rechten Ecke mit einem Finger über den Druckpunkt kommen. Nervig, wenn man anderes gewohnt ist.

ELAN-Touchpad. Ein Drücken in der rot markierten Ecke löst einen Rechtsklick aus.

Glücklicherweise kann man unter xorg Abhilfe finden, wenn auch nicht sonderlich dokumentiert. Auf einer Textkonsole in der grafischen Oberfläche kann man mit xinput eine Liste der erkannten Geräte anzeigen lassen. Hier sucht man im Abschnitt Virtual core pointer den Eintrag, welcher das Touchpad sein könnte. Meist kommt dabei das Wort „Touchpad“ im Gerätenamen vor. In der zweiten Spalte findet man eine ID, diese merkt man sich für die nächsten Befehle.

Tipp: Alternativ zur ID kann man für die nächsten Befehle auch den vollen Gerätenamen nutzen. Mit Name ist die z.B. in Scripten weniger anfällig für spontane Neu-Nummerierungen, ist aber mehr Tipparbeit, daher hier mit IDs.

Nun lässt man sich mit xinput list-props 42 die möglichen Einstellungen ausgeben. 42 entspricht hierbei der zuvor ermittelten ID. Interessant sind hierbei unter anderem Folgende Punkte:

Tapping Enabled: Hiermit schaltet man das Tippverhalten um. Im Status 1 muss man zum Klicken das Touchpad nicht mehr über den Druckpunkt drücken, sondern nur den Finger anheben und das Touchpad kurz antippen. Mit zwei Fingern gibt es einen Rechtsklick, mit drei einen Mittelklick.

Tapping Button Mapping Enabled: Hier kann man wählen, ob man das „klassische“ Zwei Finger = Mittlere Maustaste und Drei Finger = Rechte Maustaste oder das heute eher übliche Zwei Finger = Rechte Maustaste und Drei Finger = Mittlere Maustaste nutzen möchte.

Scroll Method Enabled: Hier kann man den Scrollmodus ändern. Meist ist der erste Wert „twofinger“, also Scrollen durch hoch/runter wischen mit zwei Fingern, der Zweite „edge“, also Scrollen durch hoch/runterwischen am rechten Rand und der Dritte button, Also Scrollen durch Wischen bei gedrücktem (mittlerer?) Taste.

Disable While Typing Enabled: Selbsterklärend, oder? Schaltet das Touchpad aus, während man auf der Tastatur tippt.

Click Method Enabled: Hier wird der Modus für das Klicken, also drücken über den Druckpunkt, bestimmt. Der erste Wert bedeutet „buttonareas“, also ein Rechtsklick durch einfaches drücken in der unteren, rechten Ecke. Der zweite Wert steht für „clickfinger“ und schaltet den Rechtsklick über zwei Finger ein.

Liste der Parameter eines ELAN-Touchpads

Um das von mir gewünschte Verhalten erbeizuführen muss also die Klick-Methode geändert werden. Hierbei kann nur eine der Optionen gewählt werden. Der Standard liegt bei „1, 0“, also buttonareas. Ein Ändern auf „0, 1“ bzw. clickfinger ist über folgenden Befehl möglich: xinput set-prop 42 245 0 1 – oder etwas lesbarer mit Geräte– und Optionsnamen xinput set-prop "ELAN0676:00 04F3:3195 Touchpad" 'libinput Click Method Enabled' 0 1.

Die Einstellung gilt dabei nur für die aktuelle X-Sitzung. Sollen diese Dauerhaft sein muss man die Einstellungen entweder über /etc/X11/xorg.conf.d/ vornehmen oder den obigen Befehl in den Autostart des Windowmanagers aufnehmen. Letzteres hat den Vorteil, dass die Einstellung nur für den aktuellen Nutzer gilt und man so unterschiedliche Vorlieben bedienen kann. Ich habe es entsprechend als exec in ~/.config/i3/config gepackt und kann jetzt wieder wie gewohnt rechtsklicken. Oder natürlich einfach ein paar cm weiter oben den roten Nippel nutzen und das Problem nicht haben.

Macht weniger Probleme: Der TrackPoint

Now fail already! Wenn der Browser über Umwege XOrg lahmlegt

Ugh. Schon wieder. Das Rattern in der Ecke hat meist eine recht konstante Ursache: Die CPU meines Laptops läuft auf 100% und sorgt für ordentliche Lüfterdrehzahlen. Gehen wir mal auf Ursachensuche:

Bei CPU-Last ist erster Anlaufpunkt natürlich top/htop. In meinem Fall aber leider nicht sehr Hilfreich: Xorg sei der Verursacher. Weites Feld. Aus meiner Erfahrung geht dann der Blick erst mal auf die laufenden Programme. Nicht selten hat sich auf einer geöffneten Webseite eine Flash-Werbung, ein HTML5-Video oder sonstige zappelnde Dinge mit Nervfaktor versteckt und bringen das Rendering in Gang. Leider konnte ich dieses mal nichts finden. Auch der interne Taskmanager von Google Chrome zeigt – anders als in solchen Fällen üblich – keine auffällig hohen Lasten. Um sicher zu gehen halte ich per SIGSTOP alle UI-Programme kurz an – keine Änderung. Es ist also mit hoher Wahrscheinlichkeit keine Grafikausgabe, welche die Probleme auslöst.

Zurück zum Start. Wir wissen, dass Xorg die Last bringt, allerdings vermutlich nicht im Grafikbereich. Schauen wir uns top nochmal genauer an. Die Browser sind noch in SIGSTOP und entsprechend verschwunden. Hinter XOrg macht sich nun dbus breit. Dbus? Kurze Lastspitzen OK, aber Dauerlast? Ein Blick mit dbus-monitor bringt eine Wall-of-log zum Vorschein:

method call time=1462212788.744495 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gtk.vfs.Daemon'"
method return time=1462212788.744507 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=6 reply_serial=6
method call time=1462212788.744535 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gtk.vfs.Daemon'"
method return time=1462212788.744544 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=7 reply_serial=7
method call time=1462212788.744600 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.Daemon"
   uint32 0
method return time=1462212788.744611 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=8 reply_serial=8
   uint32 2
method call time=1462212788.744748 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.gtk.vfs.Daemon"
method return time=1462212788.744761 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=9 reply_serial=9
   string ":1.1258771"
method call time=1462212788.744895 sender=:1.1259306 -> destination=:1.1258771 serial=10 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=LookupMount
   struct {
      array of bytes "/NAME@DOMAIN.org" + \0
      array [
         dict entry(
            string "query"
            variant                array of bytes "subject=blabla&body=blabla" + \0
         )
         dict entry(
            string "type"
            variant                array of bytes "mailto" + \0
         )
      ]
   }
error time=1462212788.745079 sender=:1.1258771 -> destination=:1.1259306 error_name=org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code15 reply_serial=10
   string "Der angegebene Ort wird nicht unterstützt"

…und das in Endlosschleife. Uhm, ja. mailto? Das sind üblicherweise Links in Webseiten oder Dokumenten um E-Mails zu versenden. Stimmt, ich hatte vor einigen Stunden auf einer Webseite einen Mail-Link angeklickt. Ohne Reaktion.

Offenbar hat sich die DE an eben diesem Maillink festgefressen. „Der angegebene Ort wird nicht unterstützt“. Kein Wunder, denn in den „Standardprogrammen“ ist für E-Mails nichts hinterlegt. Anstatt das Ganze aber einfach als Fehlschlag einzuordnen und abzubrechen wird die Aktion in Endlossschleife ständig wiederholt. Da auch Xorg an Dbus hängt (und offenbar nicht sonderlich effizient auf dessen Events reagiert) geht auch dieser in die Knie. Da ich auf die Schnelle keine Möglichkeit fand das dbus-event rauszuwerfen musste ein Dummy-Mailprogramm hinhalten. Event geht rein, Returncode kommt, Dbus gibt Ruhe. Warum nicht gleich so?

BitBastelei #146 – SSH unter Linux

BitBastelei #146 - SSH unter Linux

(41 MB) 00:30:06

2015-04-26 10:00 🛈
Vom Verbinden bis zum Tunneln
Alle Angaben beziehen sich auf OpenSSH

Befehle:

Verbinden zum Rechner:
ssh evil.server

Verbinden zum Rechner mit Nutzerangabe
ssh anderernutzer@evil.server

Host-Keys anzeigen
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
(bzw. passender Key)

Host-Key aus „Adressbuch“ löschen
ssh-keygen -R evil.server

Neues Schlüsselpaar erzeugen
ssh-keygen

Key auf Server kopieren
ssh-copy-id username@evil.server

Passwort eines Keys ändern
ssh-keygen -f ~/.ssh/id_rsa -p

Argumente
-p 1234 – Port 1234 statt Port 22 nutzen
-C – Kompression einschalten
-v – verbose – zusätzliche Ausgaben zur Fehlersuche

Lokale Weiterleitung
ssh -L 127.0.0.1:1234:192.168.0.2:80 evil.server
Lokale Verbindungen an Port 1234 werden über evil.server an 192.168.0.2 Port 80 weitergeleitet

Remote Weiterleitung
ssh -R 0.0.0.0:1235:127.0.0.1:80 evil.server
Verbindungen auf eine beliebige IP von evil.server auf Port 1235 werden an Port 80 des lokalen PCs weitergeleitet

SOCKS-Proxy
ssh -D 3128 evil.server
Es wird ein SOCKS-Proxy auf Port 3128 gestartet. Dieser kann z.B. mit Firefox genutzt werden

X11-Forwarding
ssh -XY evil.server
Nun können in der Sitzung grafische Programme gestartet werden. Die Anzeige erfolgt auf dem lokalen PC

Config-Files
Alle Argumente und weitere Optionen können global oder pro Ziel in den Konfigurationen hinterlegt werden. Die Benutzerkonfiguration ist unter ~/.ssh/config zu finden, die Systemweite üblicherweise unter /etc/ssh/ssh_config

Escape-Sequenz
In einer SSH-Sitzung kann man üblicherweise mit der Tilde-Taste (~) ein internes Menü aufrufen. Die Wichtigsten Befehle:
~? Hilfe anzeigen
~. SSH-Verbindung beenden (auch wenn Gegenseite nicht mehr reagiert)
~# Liste der Verbindungen (incl. Tunnel) anzeigen
~C Interne Konsole aufrufen – hier kann man nachträglich Tunnel (-L, -R, -D) aufbauen

Weitere Ideen:
– ssh-agent: Kennwörter für SSH-Keys mussen nur alle X Minuten eingegeben werden
– autossh: SSH-Verbindung bei Abbrüchen neu Aufbauen
– SSH mit Pipes: Pipes lassen sich über SSH auch an entfernte Rechner senden
2-Faktor-Anmeldung, z.B. mit Google Authenticator
Host-Keys in DNS hinterlegen

LUG-MYK

Arch Linux: Only console users are allowed to run the X server

Üblicherweise nutze ich an meinem Haupt-PC ein Multihead-Setup, also mehrere Monitore. Was zum Arbeiten praktisch ist bringt Spiele leider gerne aus dem Tritt. Um dem aus dem Weg zu gehen habe ich bisher über startx einen zweiten X-Server gestartet – direkt aus der GUI, somit war auch Pulseaudio & Co immer direkt nutzbar. Seit einem der letzten Updates, vermutlich die neue Rootless-Funktion von xorg 1.16, erscheint nur noch die Meldung „Only console users are allowed to run the X server“.

In einem Post auf Github wird empfohlen eine Datei /etc/X11/Xwrapper.config mit dem Text „allowed_users=anybody“ zu erzeugen. Generell ein Fortschritt, nun bricht jedoch beim Start der propritäre NVidia-Treiber wie folgt zusammen:

(EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed
(EE) NVIDIA(GPU-0): Failed to allocate EVO core DMA push buffer
(EE) NVIDIA(0): Failing initialization of X screen 0

Leider konnte ich den genauen Auslöser nicht finden – die Rechte sinds nicht, setuid/setgid oder start als root zeigt keine Änderung. Auch ein Wechsel auf die freien Nouveau-Treiber zeigt keine Änderung, hier kann in der zweiten Sitzung kein DRI inizialisiert werden. Glücklicherweise hat der freie Treiber deutlich weniger Rendering-Bugs – nicht nur, dass Chromium endlich wieder nutzbar ist – auch Spiele laufen nun im Multi-Monitor-Modus. Zwar erscheint das Bild immer auf den linken Monitor, aber mit einem VGA-Umschalter als Hardware-Workarround kann ich mir da behelfen.

Arch Linux: Mehrere X-Server, Systemd und VT-Switch

Die Migration auf Systemd hat noch immer ihre Nebenwirkungen auf meinem System: Ich verwende hauptsächlich ein Multimonitor-Setup auf meinem Rechner. Leider unterstützen nicht alle Anwendungen ein solches Konstrukt fehlerfrei, daher nutze ich von Zeit zu Zeit einen zweiten XOrg mit nur einem Monitor um die Software zu betreiben. Um diesen zu starten nutzte ich bisher den Befehl startx -- :1 -layout LayoutSingle. Über das übliche VT-Switch konnte ich ggf. zwischen den Serven wechseln, die Multimonitor-Lösung befand sich auf vt7 (Ctrl-Alt-F7) und der zweite Server mit nur einem Monitor auf vt8 (Ctrl-Alt-F8).

Nach der Migration auf Systemd war damit Schluss: Zwar startete der zweite X-Server normal und ich konnte ihn benutzen, habe ich ihn aber einmal auf eine andere Konsole verlassen gab es keine Möglichkeit mehr auf den Bildschirm zurück zu kommen. Zum Glück ist die Lösung recht einfach und offensichtlich (wenn man sie erst mal gefunden hat) – der Befehl zum Starten heißt nun startx -- :1 -layout LayoutSingle vt8