Warum die Bildschirmaufnahme den falschen Monitor erfasst (und unser Fix)

Hier ist ein Bug, der nur existiert, wenn du zwei Monitore besitzt — deshalb lebte er eine Weile still vor sich hin. Du arbeitest auf deinem seitlichen Display, startest eine GeekBye-Aufnahme, und sie nimmt deinen Hauptmonitor auf. Den mit der Menüleiste. Den, den du nicht angeschaut hast.

Derselbe Defekt, leiser und schlimmer, traf die Screenshots, die GeekBye zur Kontextgebung an die KI schickt: Drück den Screenshot-Shortcut auf deinem zweiten Monitor, und die KI bekommt ein Bild von deinem ersten. Es gibt kein visuelles Anzeichen — der Assistent antwortet einfach über den falschen Bildschirm, und du fragst dich, warum er so verwirrt ist. GeekBye v2.0.10 hat beides behoben.

Zwei Pipelines, ein und dieselbe faule Standardwahl

Bildschirmaufnahme auf dem Desktop sind zwei getrennte Codepfade, und beide hatten unabhängig voneinander den Hauptbildschirm gewählt:

• Die Videoaufnahme zählte die verfügbaren Bildschirmquellen auf und nahm die erste — sources[0]. Auf macOS ist das praktisch immer das Hauptdisplay. Kein Picker, keine Logik dazu, wo du eigentlich warst. Der Kommentar in unserem eigenen Code lautete wörtlich "auto-select first screen source."
• Die Screenshots nutzten den macOS-Befehl screencapture mit dem Flag -m. Dieses Flag hat genau eine Bedeutung: nur Hauptbildschirm. Fest verdrahtet.

Keiner der beiden Pfade stellte je die Frage, auf die es ankommt: Auf welchem Bildschirm ist der Nutzer?

Eine Sache, die nie kaputt war und die zu klären sich lohnt, weil man das Gegenteil annimmt: Der Wechsel zwischen macOS-Spaces auf demselben Monitor funktionierte immer. Die Aufnahme geschieht auf Display-Ebene — sie greift den Space, der auf dem gewählten Display sichtbar ist. Beim Bug ging es nie um Spaces. Es ging immer um die Wahl des falschen physischen Displays.

Der Fix, der offensichtlich aussah — und falsch war

Das richtige Signal scheint einfach: das Display aufnehmen, auf dem der Nutzer ist. Unsere erste Implementierung verankerte sich am Overlay-Fenster von GeekBye — nimm das Display auf, auf dem das Overlay lebt.

Das Code-Review killte sie, zu Recht. GeekByes Overlay wird als Fenster über den gesamten Arbeitsbereich auf dem Hauptdisplay erzeugt, an Position (0,0). Es wandert nur zu einem anderen Monitor, wenn du seine Pille physisch dorthin ziehst — und die Tastatur-Shortcuts, die es verschieben, klemmen auf die Maße des Hauptdisplays, können es also überhaupt nicht auf einen zweiten Monitor bewegen. Die Aufnahme am Overlay zu verankern bedeutete: Für jeden Nutzer, der das Overlay nicht zufällig auf seinen Arbeitsbildschirm gezogen hatte, löste der „Fix" direkt wieder auf den Hauptbildschirm auf. Er hätte fast niemandem geholfen — während er in einem schnellen Test auf einer Single-Monitor-Dev-Maschine so aussah, als würde er funktionieren.

Der richtige Anker ist der Cursor. Wo deine Maus ist, das ist das Display, auf dem du arbeitest — und das stimmt für jede Art, wie eine Aufnahme startet: Ein Tastatur-Shortcut feuert dort, wo du zeigst, und ein Klick auf den Aufnehmen-Button setzt deinen Cursor per Definition auf dieses Display. Der finale Fix ist eine zweizeilige Funktion: das Display, das dem Cursor am nächsten ist. Video richtet seine Aufnahmequelle nach der id dieses Displays aus; Screenshots übergeben die Grenzen dieses Displays an screencapture -R (ein bestimmtes Rechteck) statt des -m-Hauptdisplay-Flags.

Wir haben -R (ein explizites Rechteck in globalen Bildschirmkoordinaten) bewusst gegenüber -D (einem Display-Index) gewählt: Der Display-Index des Betriebssystems hat keine garantierte Entsprechung zur Display-Reihenfolge des Frameworks, ein Index wäre also ein zweites Ratespiel. Ein Rechteck aus den tatsächlichen Display-Grenzen ist eindeutig — und wir haben das Verhalten des Flags, inklusive negativer Koordinaten für Displays links vom Hauptbildschirm, vor der Auslieferung an einem echten Multi-Monitor-Aufbau verifiziert.

Warum das ein guter Lehr-Bug ist

1. „Nimm den Bildschirm auf" verbirgt eine Entscheidung. Auf einem einzelnen Display gibt es keine Entscheidung, also wird die Entscheidung nie designt — sie wird per Default getroffen. Multi-Monitor ist der Ort, an dem jeder implizite Standard an die Oberfläche kommt.
2. Still-falsch ist schlimmer als sichtbar-falsch. Der Video-Bug nervte die Leute. Der Screenshot-Bug führte die KI in die Irre, unsichtbar. Wenn du Features baust, die einem Modell Kontext zuführen, produziert eine falsche Eingabe eine selbstbewusst falsche Ausgabe — ohne irgendwo einen Fehler. Genau diese Fehler lohnt es sich am härtesten zu jagen.
3. Ein Fix, der auf deiner Maschine besteht, kann auf der von allen anderen scheitern. Die am Overlay verankerte Version funktionierte in einem Single-Monitor-Test. Der ganze Sinn des Bugs sind mehrere Monitore — und der Reviewer schlussfolgerte über die reale Fensterposition, statt dem grünen Test zu vertrauen. Ein Review ist kein Gummistempel auf funktionierendem Code; es ist ein zweites Modell davon, warum der Code funktioniert.

GeekBye v2.0.10 liefert den cursorbasierten Fix sowohl für die Aufnahme als auch für die Screenshots. Wenn du mehrere Displays betreibst, folgt dir die Aufnahme jetzt.

Für die benachbarten Releases dieser Serie siehe warum dein KI-Notetaker mitten im Meeting die Aufnahme stoppt (v2.0.9) und warum KI-Transkription Fachbegriffe falsch versteht (v2.0.11). Wie sich das Overlay während Anrufen verhält, siehe wie du beim Screen-Sharing unsichtbar bleibst.