HN montre : un outil X11 pour partager une zone de l’écran dans toutes les visioconférences

• clipscreen est une application X11 simple qui crée un moniteur virtuel reflétant une zone précise de l’écran et affiche cette zone avec un rectangle vert
• Dans des outils de partage d’écran comme Google Meet, Microsoft Teams ou Jitsi Meet, il est possible de partager ce moniteur virtuel au lieu de l’écran complet ou d’une fenêtre individuelle
• Il suffit de déplacer la fenêtre à partager à l’intérieur du cadre vert, ce qui réduit le besoin de partager plusieurs fenêtres séparément ou de changer de cible de partage
• L’exécution se fait au format ./clipscreen <width>x<height>+<x>+<y>, et il est aussi possible d’utiliser hacksaw ou slop pour une sélection interactive de zone
• Le programme n’a été testé que sur Linux et xorg, sans garantie de fonctionnement sur d’autres systèmes

---

Ce que fait clipscreen

• clipscreen est une application qui crée un moniteur virtuel répliquant une partie de l’écran
• La zone d’écran définie est mise en évidence par un rectangle vert
• L’utilisateur peut partager ce moniteur virtuel via les outils habituels de partage d’écran en visioconférence
  • ex. : Google Meet
  • Microsoft Teams
  • Jitsi Meet

Méthode de partage d’écran

• Au lieu de partager l’écran entier ou chaque fenêtre séparément, on partage le moniteur virtuel créé par clipscreen
• Il suffit de déplacer la fenêtre à partager à l’intérieur du cadre vert
• Cette méthode évite d’avoir à changer en permanence de fenêtre partagée lorsqu’on travaille avec plusieurs fenêtres

Prérequis de compilation

• Les éléments suivants sont nécessaires sur le système

  • Bibliothèques de développement X11

    • Bibliothèque graphique Cairo
    • Compilateur C, par ex. gcc
    • Sur Ubuntu 24.04, les bibliothèques nécessaires peuvent être installées avec la commande suivante

apt-get install libx11-dev xserver-xorg-dev xorg-dev libcairo2-dev gcc

- La compilation s’effectue avec la commande suivante

make

- L’application n’a été testée que sur **Linux et xorg**, et son fonctionnement sur d’autres systèmes n’est pas garanti

Utilisation

• Le binaire compilé s’exécute au format suivant

./clipscreen <width>x<height>+<x>+<y>

• Les arguments définissent la position et la taille de l’overlay et du moniteur virtuel
  • <width> : largeur de l’overlay et du moniteur virtuel
  • <height> : hauteur de l’overlay et du moniteur virtuel
  • <x> : coordonnée x du coin supérieur gauche de l’overlay et du moniteur virtuel
  • <y> : coordonnée y du coin supérieur gauche de l’overlay et du moniteur virtuel
• Exemple

./clipscreen 800x600+100+100

• Cette commande crée une fenêtre d’overlay 800x600 commençant à la position (100, 100) de l’écran

Sélection interactive de zone et fermeture

• Pour sélectionner une zone de manière interactive, il est possible d’exécuter la commande avec hacksaw ou slop

./clipscreen $(hacksaw)

./clipscreen $(slop)

• Outils associés
  • hacksaw
  • slop
• Pour quitter, il suffit d’appuyer sur Ctrl+C dans le terminal où l’application est en cours d’exécution

[GN⁺]

Commentaires sur Hacker News

• Le partage d’écran Google Meet était pénible sur un moniteur ultrawide de 49 pouces. On ne peut partager qu’une fenêtre ou tout l’écran, pas une zone précise de l’écran.
  J’ai donc créé un petit outil qui utilise l’extension xrandr pour refléter une zone donnée vers un moniteur virtuel, que l’on peut ensuite partager.
  Plus de détails dans ce billet de blog : https://www.splitbrain.org/blog/2024-10/11-introducing_clips...
  • Ça a l’air vraiment utile quand on dispose d’un grand écran. Un 27 pouces n’offre pas autant d’espace de travail qu’un 49 pouces, donc j’utilise un script qui lance une fenêtre Xephyr séparée sur DISPLAY 9 et place plusieurs fenêtres sur cet écran.
    Je l’utilise ainsi comme environnement de démo : https://gist.github.com/radupotop/d77a47767e2e65a7e7d40d1ea8...
• J’aime la simplicité du truc. Sans les commentaires, ça fait à peine une centaine de lignes de C++, et c’est ce genre de choses qui me fait préférer X11 à Wayland.
  • Le code est un peu étrange. Il n’y a pas de boucle d’événements XLib et, jusqu’à la réception d’un SIGINT, la boucle appelle sleep(100).
    À cause de ça, l’utilisation CPU peut monter sans vraie raison.
  • Sous Wayland, quand on lance une capture via l’API xdg-desktop-portal, l’utilisateur reçoit une notification et peut choisir la zone à capturer.
  • Créer un affichage Xrandr virtuel qui chevauche l’affichage physique existant est quasiment un élégant numéro de démonstration X.org, difficile à reproduire facilement dans d’autres systèmes de fenêtres.
    Si le programme se termine autrement que par SIGINT, seule la sortie virtuelle peut rester tandis que la fenêtre d’overlay disparaît, ce qui est un peu maladroit, mais pas très grave. Cela dit, mieux vaut ne pas considérer trop fortement le nombre de lignes de code comme une mesure de qualité ou d’élégance.
    Cette approche n’est pas transposable telle quelle à Wayland. En revanche, sous Wayland, cet outil n’est peut-être tout simplement pas nécessaire. La méthode standard pour qu’un processus non privilégié capture l’écran passe par les portails desktop, et KDE au moins prend en charge de nombreuses options de capture, dont la capture d’un rectangle de l’écran. Même avec une application X.org, cela devrait être possible grâce à XWaylandVideoBridge.
    Le fait que D-Bus soit utilisé un peu partout ne m’enchante pas vraiment, mais j’aime bien l’idée qu’en changeant l’implémentation de org.freedesktop.impl.portal.ScreenCast, on puisse remplacer à peu près le comportement de capture d’écran souhaité. C’est, à mon avis, une meilleure direction que de laisser chaque application implémenter à sa manière la sélection de la cible de capture.
  • S’il y a si peu de code, c’est surtout parce qu’il n’y a presque pas de gestion des erreurs ni de vérifications de validité.
    Ça ne veut pas dire que X11 n’est pas agréable et cool à bidouiller, mais dès qu’on ne suppose plus uniquement des usages parfaits, le code gonfle et se complexifie, tout en devenant plus robuste.
    Par exemple, essayez d’exécuter ./clipscreen 1 2 3 4.
  • Je ne cherche pas à nier des décennies de débats sur ses nombreux défauts, mais il est surprenant de voir à quel point X11 en est venu à apparaître comme l’environnement graphique de bureau utilisable le plus simple et le plus facile à bidouiller.
    Si on veut bricoler quelque chose, on peut le faire tout de suite. L’ICCCM s’est fait énormément critiquer au début des années 90, mais il n’y a pas vraiment d’équivalent ailleurs, et le domaine des gestionnaires de fenêtres continue encore aujourd’hui à voir apparaître de nouvelles expérimentations.
• Il me semble que Zoom permettait de partager plusieurs éléments, et pas seulement un écran ou une fenêtre. Il faut maintenir la touche SHFT en cliquant sur les fenêtres à partager.
  • Comment est-on censé découvrir ce genre de fonctionnalité ?
• On peut littéralement faire ça avec xrandr seul.
  xrandr --setmonitor screenshare 2560/1x1440/1+0+0 none
  • Pour rendre la sélection interactive, on peut faire ainsi :
    geo=$(slop -f '%w/1x%h/1+%x+%y') && xrandr --setmonitor screenshare "$geo" none
  • Pour être juste, cet outil fait finalement la même chose, plus l’overlay, en C++.
    Mais ça reste une très belle commande en une ligne.
• Est-ce qu’OBS ne permet pas déjà de faire ça sur n’importe quelle plateforme, y compris Wayland ? En lisant plusieurs commentaires, j’ai l’impression que beaucoup de gens ne connaissent pas OBS, ou alors que je surestime ses fonctionnalités.
  • C’est probablement possible. Je n’ai jamais utilisé OBS, mais il doit sans doute être un peu plus gros qu’un binaire de 20 Ko.
  • C’est possible, mais ça demande un peu plus de manipulation. Il faut passer par plusieurs étapes dans l’interface graphique, et si l’on doit tout réajuster avant chaque réunion, ça devient assez fastidieux.
  • OBS ne permet de partager qu’une fenêtre ou la zone cliente d’une application.
• Sur un moniteur 49 pouces, je combine OBS, un script qui suit la souris et la fenêtre de prévisualisation OBS sur l’écran du laptop, puis je partage tout l’écran du laptop.
  Cela permet de savoir si la taille de la fenêtre est adaptée à quelqu’un qui regarde depuis un ordinateur portable, et la prévisualisation suit la souris tout en permettant d’ajuster à la volée le niveau de zoom et les limites autour du pointeur.
  La fenêtre de prévisualisation OBS s’ouvre au lancement sans la fenêtre principale d’OBS, donc ensuite je n’ai plus besoin de voir ni de manipuler la fenêtre principale ou l’application, ce qui donne l’impression d’un outil autonome.
  https://github.com/BlankSourceCode/obs-zoom-to-mouse
• Sous KDE 6.1, Wayland et Chromium, quand on clique sur le bouton de partage d’un service comme Jitsi, l’option de partage Entire Screen apparaît d’abord, puis une boîte de dialogue propose Full Workspace, New Virtual Output, Rectangular Region ainsi qu’une liste d’écrans.
  Rectangular Region permet de partager une partie choisie de l’écran, et New Virtual Output crée immédiatement un écran virtuel visible dans KDE Display Configuration. Cet écran virtuel peut être placé en chevauchement avec un écran physique existant, ou non.
• Vraiment excellent. Sous Linux, c’est précisément à cause de ce cas d’usage que notre entreprise a choisi Zoom plutôt que Meet.
  • Je l’ai compilé moi-même, puis j’ai pris une capture de tout l’écran avec GIMP pour déterminer la largeur, la hauteur et les coordonnées x/y voulues, et je l’ai testé dans Google Meet. Ça fonctionne parfaitement.
• On peut aussi faire ça avec xzoom, avec un grossissement supérieur à 1× en plus ; y a-t-il un avantage que je rate ?
• Je me demande pourquoi les plateformes de visioconférence actuelles ne répondent toujours pas à ce besoin. Les moniteurs géants deviennent de plus en plus courants, surtout chez les développeurs susceptibles de créer ce genre d’outil.
  • C’est peut-être parce que le contournement avec OBS n’est pas très difficile.