HN veröffentlicht: X11-Tool zum Teilen eines Bildschirmbereichs in jeder Videokonferenz

 (github.com/splitbrain)
1 Punkte von GN⁺ 2024-10-15 | 1 Kommentare | Auf WhatsApp teilen
  • clipscreen ist eine einfache X11-Anwendung, die einen virtuellen Monitor erstellt, der einen bestimmten Bereich des Bildschirms spiegelt, und diesen Bereich mit einem grünen Rechteck markiert
  • In Screen-Sharing-Tools wie Google Meet, Microsoft Teams und Jitsi Meet kann man statt des gesamten Bildschirms oder einzelner Fenster den virtuellen Monitor freigeben
  • Man verschiebt einfach das gewünschte Fenster in den grünen Rahmen, wodurch es seltener nötig ist, mehrere Fenster einzeln zu teilen oder das Freigabeziel zu wechseln
  • Der Start erfolgt im Format ./clipscreen <width>x<height>+<x>+<y>; zusammen mit hacksaw oder slop ist auch eine interaktive Bereichsauswahl möglich
  • Getestet wurde es nur unter Linux und xorg; auf anderen Systemen ist die Funktion nicht garantiert

Was clipscreen macht

  • clipscreen ist eine Anwendung, die einen virtuellen Monitor erzeugt, der einen Teil des Bildschirms dupliziert
  • Der festgelegte Bildschirmbereich wird mit einem grünen Rechteck hervorgehoben
  • Nutzer können diesen virtuellen Monitor in gewöhnlichen Screen-Sharing-Tools für Videokonferenzen freigeben
    • z. B. Google Meet
    • Microsoft Teams
    • Jitsi Meet

Art der Bildschirmfreigabe

  • Statt den gesamten Bildschirm oder einzelne Fenster separat freizugeben, teilt man den von clipscreen erzeugten virtuellen Monitor
  • Das freizugebende Fenster muss nur in den grünen Rahmen verschoben werden
  • So muss man bei mehreren Fenstern nicht ständig das geteilte Fenster wechseln

Build-Anforderungen

  • Auf dem System werden die folgenden Komponenten benötigt

    • X11-Entwicklungsbibliotheken

      • Cairo-Grafikbibliothek
      • C-Compiler, z. B. gcc
      • Unter Ubuntu 24.04 lassen sich die benötigten Bibliotheken mit folgendem Befehl installieren
apt-get install libx11-dev xserver-xorg-dev xorg-dev libcairo2-dev gcc

- Der Build wird mit folgendem Befehl ausgeführt

make

- Die Anwendung wurde nur unter **Linux und xorg** getestet; ob sie auf anderen Systemen funktioniert, ist unklar

Verwendung

  • Die kompilierte ausführbare Datei wird im folgenden Format gestartet
./clipscreen <width>x<height>+<x>+<y>
  • Die Argumente legen Position und Größe von Overlay und virtuellem Monitor fest
    • <width>: Breite von Overlay und virtuellem Monitor
    • <height>: Höhe von Overlay und virtuellem Monitor
    • <x>: x-Koordinate der linken oberen Ecke von Overlay und virtuellem Monitor
    • <y>: y-Koordinate der linken oberen Ecke von Overlay und virtuellem Monitor
  • Ein Beispiel sieht so aus
./clipscreen 800x600+100+100
  • Dieser Befehl erzeugt ein 800x600 großes Overlay-Fenster, das an der Position (100, 100) auf dem Bildschirm beginnt

Interaktive Bereichsauswahl und Beenden

  • Um den Bereich interaktiv auszuwählen, kann man es zusammen mit hacksaw oder slop ausführen
./clipscreen $(hacksaw)

./clipscreen $(slop)
  • Zugehörige Tools
  • Zum Beenden drückt man im Terminal, in dem die Anwendung läuft, Ctrl+C

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-15
Kommentare auf Hacker News
  • Auf einem 49-Zoll-Ultrawide-Monitor war das Teilen des Bildschirms in Google Meet unpraktisch. Man kann nur ein einzelnes Fenster oder den gesamten Bildschirm teilen, aber keinen Teilbereich des Bildschirms.
    Deshalb wurde mit der xrandr-Erweiterung ein kleines Tool gebaut, das einen bestimmten Bereich auf einen virtuellen Monitor spiegelt, den man dann teilen kann.
    Details gibt es im Blogbeitrag: https://www.splitbrain.org/blog/2024-10/11-introducing_clips...
    • Sieht wirklich nützlich aus, wenn man einen großen Bildschirm nutzen kann. Ein 27-Zoll-Display bietet nicht so viel Arbeitsfläche wie 49 Zoll; deshalb nutze ich ein Skript, das ein separates Xephyr-Fenster auf DISPLAY 9 startet und mehrere Fenster auf diesen Bildschirm legt.
      So nutze ich es als Demo-Umgebung: https://gist.github.com/radupotop/d77a47767e2e65a7e7d40d1ea8...
  • Mir gefällt, wie einfach das ist. Ohne Kommentare sind es nur gut 100 Zeilen C++, und genau wegen solcher Dinge bevorzuge ich X11 gegenüber Wayland.
    • Der Code ist etwas seltsam. Es gibt keine XLib-Event-Loop, und bis SIGINT empfangen wird, ruft die Schleife sleep(100) auf.
      Dadurch kann die CPU-Auslastung ohne besonderen Grund steigen.
    • Unter Wayland zeigt die xdg-desktop-portal API beim Starten einer Aufnahme eine Benachrichtigung an und lässt den Nutzer den aufzunehmenden Bereich auswählen.
    • Ein virtuelles Xrandr-Display zu erzeugen, das sich mit einem vorhandenen physischen Display überlappt, ist fast schon ein eleganter X.org-Partytrick, den kaum ein anderes Fenstersystem so einfach hinbekommt.
      Wenn das Programm anders als per SIGINT beendet wird, kann der virtuelle Output übrig bleiben, während das Overlay-Fenster verschwindet; das ist etwas unschön, aber kein großes Problem. Trotzdem sollte man die Zahl der Codezeilen nicht zu sehr als Maß für Qualität oder Eleganz nehmen.
      Dieser Ansatz ist unter Wayland nicht direkt möglich. Dafür braucht man dieses Tool unter Wayland vielleicht von vornherein nicht. Der Standardweg, mit dem ein Prozess ohne besondere Berechtigungen den Bildschirm aufnimmt, ist das Desktop-Portal, und zumindest KDE unterstützt verschiedene Aufnahmeoptionen, einschließlich der Aufnahme eines Bildschirmrechtecks. Selbst wenn eine X.org-App läuft, dürfte das dank XWaylandVideoBridge möglich sein.
      Dass D-Bus überall eingesetzt wird, ist nicht gerade erfreulich, aber es ist gut, dass man durch Austausch der Implementierung von org.freedesktop.impl.portal.ScreenCast das gewünschte Verhalten für Bildschirmaufnahmen weitgehend ersetzen kann. Das ist meiner Ansicht nach besser, als wenn jede App ihre eigene Auswahlfunktion für Aufnahmequellen implementiert.
    • Der Code ist vor allem deshalb so kurz, weil es fast keine Fehlerbehandlung und Plausibilitätsprüfungen gibt.
      Das heißt nicht, dass X11 nicht hackbar und cool wäre, aber wenn man nicht nur perfekte Nutzung annehmen will, wird der Code größer und komplexer – und entsprechend robuster.
      Man kann zum Beispiel ./clipscreen 1 2 3 4 ausführen.
    • Ich will die jahrzehntelangen Debatten über die vielen Mängel nicht abstreiten, aber es ist erstaunlich, dass X11 heute wie die einfachste und am leichtesten hackbare der nutzbaren Desktop-Grafikumgebungen wirkt.
      Wenn man etwas herumspielen will, geht das sofort. ICCCM wurde Anfang der 90er heftig kritisiert, aber auf der anderen Seite gibt es nichts Vergleichbares, und im Bereich Window Manager entstehen bis heute immer wieder neue Ansätze.
  • Ich meine, bei Zoom konnte man nicht nur einen Bildschirm oder ein Fenster teilen, sondern mehrere. Beim Anklicken der Fenster, die man teilen will, hält man die SHFT-Taste gedrückt.
    • Wie findet man so eine Funktion überhaupt heraus?
  • Das geht buchstäblich auch nur mit xrandr.
    xrandr --setmonitor screenshare 2560/1x1440/1+0+0 none
    • Wenn die Auswahl interaktiv sein soll, geht es so:
      geo=$(slop -f '%w/1x%h/1+%x+%y') && xrandr --setmonitor screenshare "$geo" none
    • Fairerweise macht dieses Tool am Ende genau diese Aufgabe plus Overlay in C++.
      Trotzdem ein schöner Einzeiler.
  • Kann man das nicht mit OBS auf jeder Plattform, einschließlich Wayland, machen? Beim Lesen mehrerer Kommentare habe ich den Eindruck, dass viele OBS nicht kennen – oder dass ich die Fähigkeiten von OBS überschätze.
    • Vermutlich geht das. Ich habe OBS nie benutzt, aber es ist wahrscheinlich etwas größer als ein 20-KB-Binary.
    • Es geht, macht aber etwas mehr Arbeit. Man muss mehrere Schritte in der GUI durchlaufen, und wenn man das vor jedem Meeting jedes Mal anpassen muss, wird es ziemlich lästig.
    • OBS lässt einen nur ein einzelnes Fenster oder den Client-Bereich einer App teilen.
  • Auf einem 49-Zoll-Monitor kombiniere ich OBS, ein Skript, das der Maus folgt, und das OBS-Vorschaufenster auf dem Laptopbildschirm und teile dann den gesamten Laptopbildschirm.
    So kann ich sehen, ob die Fenstergröße für andere auf einem Laptop gut lesbar ist, und die Vorschau folgt der Maus, während ich Zoomstufe und Mausgrenzen spontan anpassen kann.
    Gut ist, dass das OBS-Vorschaufenster beim Start ohne das Hauptfenster von OBS geöffnet wird; danach muss man das Hauptfenster oder die App weder sehen noch bedienen, wodurch es sich fast wie ein eigenständiges Tool anfühlt.
    https://github.com/BlankSourceCode/obs-zoom-to-mouse
  • Wenn man unter KDE 6.1, Wayland und Chromium bei einem Dienst wie Jitsi auf den Teilen-Button klickt, erscheint zuerst die Option Entire Screen zum Teilen, danach ein Dialog mit Full Workspace, New Virtual Output, Rectangular Region sowie einer Liste der Displays.
    Rectangular Region kann einen ausgewählten Teil des Bildschirms teilen, und New Virtual Output erzeugt sofort einen virtuellen Bildschirm, der in der KDE Display Configuration sichtbar ist. Dieser virtuelle Bildschirm kann über einem vorhandenen physischen Display platziert werden oder auch nicht.
  • Wirklich großartig. Genau wegen dieses Use Cases unter Linux hat sich unser Unternehmen für Zoom statt Meet entschieden.
    • Ich habe es selbst gebaut, dann mit GIMP einen Vollbild-Screenshot gemacht, um die gewünschten Werte für Breite, Höhe sowie x/y-Koordinaten herauszufinden, und es in Google Meet getestet. Funktioniert perfekt.
  • Mit xzoom kann man das ebenfalls machen und sogar stärker als 1-fach vergrößern; übersehe ich vielleicht einen Vorteil?
  • Ich frage mich, warum diese Anforderung von den heutigen Videokonferenzplattformen immer noch nicht erfüllt wird. Riesige Monitore werden immer verbreiteter, besonders bei den Entwicklern, die solche Tools bauen würden.
    • Vielleicht, weil der Workaround über OBS nicht besonders schwierig ist.