O-LED-Monitore? Ist das was?

[pit234a]

Ich behelfe mir da mit einem Aufruf von xrandr. Das habe ich mir dafuer auch schon extra in ein Shell Skript verpackt.
Ist nicht DIE Loesung, aber sie funktioniert.

nur leider nicht für Wayland...

Wer und wie steuert denn eigentlich die Maus im Wayland?
Womöglich gibt es da etwas einzustellen und ich war nur zu dumm, es zu finden.
Oder womöglich sogar komfortable SW, die auch die bewegte Maus größer darstellt oder so was.

 

[bluescreen]

Hallo ,

vielleicht hilft ja wlr-randr weiter ...

Gruss

 

[pit234a]

vielleicht hilft ja wlr-randr weiter ...

tatsächlich schon.

Das ist aber vielleicht dann doch ein neues Thema, obwohl es erst mit den beiden neuen Monitoren aufgetreten ist und insofern ja dann doch auch noch hier passt.
Vielleicht haben die Mods ein wachsames Auge und ergreifen geeignete Maßnahmen.

Zur Erklärung:
in meiner labwc autostart habe ich ziemlich zu Anfang folgende Zeile drin:

wlr-randr --output DP-1 --pos 3840,0 --output DP-2 --preferred --pos 0,0

Frag mich keiner, warum ich das so haben wollte. Wenn ich es heute betrachte, kommt es mir unsinnig verdreht vor. Vermutlich war die Aufteilung der Monitore schon unter Openbox so gewachsen, wobei ich aber auch keinen Grund dafür erinnern kann.

Wie auch immer: so funktioniert all das, was ich brauche, wie ich es will. Also nach Start der labwc-Sitzung werden alle Fenter der automatisch geladenen Programme dorthin verteilt, wo ich das gerne habe. Vor Allem aber läuft die Maus richtig über die Monitore, also von 0,0 auf dem linken Rand am linken Monitor bis zum rechten Rand des rechten Monitors.
Nachdem nun swayidle die beiden Monitore in den resume geschickt hat, erwachen diese aber irgendwie falsch.
Leider kann ich das nicht gut beschreiben.
Fast alles stimmt noch immer, wie es sein soll. Manchmal ist ein oder vielleicht auch zwei Fenster auf den falschen Monitor gewandert. Aber IMMER fängt nun die Maus auf dem linken Rand des rechten Monitors an zu zählen.
Nun habe ich dummerweise im Übereifer nicht angesehen, was wlr-rander dazu nun sagt, sondern gleich den selben Ausdruck wie in der autostart von Konsole aufgerufen (ich habe das als root gemacht, denke, das wlr-rander zum Ändern als root aufgerufen sein will, habe aber dazu nicht nachgelesen).
Im Ergebnis läuft die Maus nun sofort wieder, wie sie das auch soll.

Ich möchte nicht experimentieren um schneller voran zu kommen, sondern Abwarten, bis das nächste Mal der Fall auftritt und dann erst mal sehen, was wlr-rander dazu ausgibt.

 

[pit234a]

Ich möchte nicht experimentieren um schneller voran zu kommen, sondern Abwarten, bis das nächste Mal der Fall auftritt und dann erst mal sehen, was wlr-rander dazu ausgibt.

schneller, als geplant:

DP2:	Gut:	x=0	y=0	Schlecht:	x=3840	y=0
DP1:	Gut:	x=3840	y=0	Schlecht:	x=0	y=0

Das passt irgendwie zu meiner Beobachtung und auch dazu, dass

# wlr-randr --output DP-1 --pos 3840,0 --output DP-2 --preferred --pos 0,0

das wieder richtet.

# wlr-randr --output DP-2 --right-of DP-1

hatte indessen keinen Einfluss.

Nach welchem Gesetz sich einzelne Fenster verschieben, erkenne ich noch nicht wirklich, es könnte aber mit der Option --preferred in meinem Aufruf zusammen hängen, die ich sicher irgendwo abgeschrieben habe, denn auf die Schnelle finde ich dazu keine wirkliche Erklärung.
Weil der nächste Fall bestimmt wieder früher eintritt, als geplant, habe ich den wlr-randr Aufruf nun mal ohne diese Option wiederholt.

 

[pit234a]

habe ich den wlr-randr Aufruf nun mal ohne diese Option wiederholt.

was genau gleiches Ergebnis zeigte.

Immerhin ist mit Anwendung des Befehls das größte Übel sehr flott erledigt. Die wenigen Fenster, die sich verschieben, sind nicht wirklich lästig.

Stellt sich natürlich die Frage, nach einem Automatismus und ich bin da überfordert.
In meiner labwc/autostart steht nun:

swayidle -w \
    timeout 600 'swaylock -f -c 000000' timeout 900 'wlopm --off \*' resume 'wlopm --on \*' >/dev/null 2>&1 &

Soweit ich das verstehe, werden die Optionen oder eher Kommandos irgendwie verkettet und resume 'wlopm --on \*' bringt die Monitore wieder zum Leben, bzw, lässt den User wieder drauf. Genau hier würde dann der wlr-randr sich ja gut machen.
Weiß jemand vielleicht wie?
Mir ist die Syntax da ziemlich verwirrend.

 

[pit234a]

siehe hier.
kanshi (x11/kanshi) kann die Positionen und Auflösungen der Monitore gemäß seiner config erhalten, auch über das Aufwachen hinaus.
Damit erledigt sich das Maus-Problem.

Die "falsch" platzierten Fenster lassen sich durch ein einfaches labwc --reconfigure an ihren "richtigen" Platz befördern. Automatisiert habe ich das noch nicht.

 

[pit234a]

Automatisiert habe ich das noch nicht.

und bekomme das auch nicht wirklich hin.

Nochmal zum Stand der Dinge:
statt x11/kanshi nutze ich nun x11/shikane, weil ich es etwas einfacher verstanden habe und es auch etwas mehr kann und etwas moderner ist.
Damit erhalte ich den Zustand (wie auch schon mit kanshi), dass nach Aufwachen der Monitore deren Position erhalten bleibt und kein Maus-Problem auftritt.
Die Monitore wachen aber doch nacheinander auf und dies nicht ganz regelmäßig. Meist ist jener am DP-2 schneller fertig, aber nicht immer. labwc ordnet dann aber schon manche Fenster neu an (weil es ja für kurze Zeit gar keinen zweiten Monitor sieht).
Ein einfaches labwc --reconfigure schafft dann gut Abhilfe.

In dem Befehl

swayidle -w timeout 600 'swaylock -f -c 000000' timeout 900 'wlopm --off \' resume 'wlopm --on \' >/dev/null 2>&1 &

kann
resume 'wlopm --on'
durch
resume 'sh /my/wakeup.sh'
ersetzt werden.
Das 'wlopm --on' landet dann in /my/wakeup.sh und weiter dann die nächsten Befehle, also auch labwc --reconfigure.

Das funktioniert, solange die Monitore im Standby sind. Nachdem sie aber in Deep-Standby waren, versagen die Befehle nach dem wlopm --on, vermutlich, weil es einfach sehr lange dauert, bis die Monitore wieder richtig wach sind. Doch selbst mit sleep von 25 Sekunden lief es einfach nicht, so dass ich das aufgegeben habe.

labwc bietet ein "rechter-Maus-Klick auf den Hintergrund" -Menü und da gibt es per Default die alte Schaltfläche "Reconfigure Openbox", die aber genau ein labwc --reconfigure durchführt. Da musste ich gar nicht erst Hand anlegen (in der menu.xml) .
Zusätzlich habe ich eine Tastenkombination dafür in der labwc rc.xml abgelegt, aber noch nicht getestet.

So richtig automatisiert kann man das zwar nicht nennen, aber mir hilft das und ich kann damit leben.

 

[Kamikaze]

Hier ist meine .config/swayidle/config:

timeout 60 'swaymsg "output * power off"' resume 'swaymsg "output * power on"'
timeout 70 'swaylock -f -c 000000'

Was die macht ist nach 60 Sekunden Idle alle Video outputs zu deaktivieren. Bei der ersten Nutzerinteraktion werden alle Video outputs wieder aktiviert (der resume Teil).

Weitere 10s später (also nach insgesamt 70s Timeout) wird swaylock aufgerufen um die Sitzung zu sperren. Dadurch hat man wenn der Bildschirm dunkel wird noch 10s Zeit um das Sperren der Sitzung zu verhindern.

In der .config/sway/config steht nur noch exec swayidle -w.

 

[pit234a]

.config/swayidle/config

ich dachte, es zunächst ohne config zu machen, da mein Befehl ja einfach genug ausgesehen hatte, ihn direkt zu tippen.
Tatsächlich hatte ich dann aber keinen Erfolg damit, den swaylock nach wlopm --off zu platzieren; werde es wohl auch mit einer config versuchen, weil das Verhalten mir lieber ist, wie du es beschreibst.

Irgendwo in den Weiten des Netzes hatte ich dann auch gelesen, dass dringend der Gebrauch von wlopm im Zusammenhang mit Wayland geraten sei. Nunja, es funktioniert, macht aber im Grunde nichts anderes, als power off - on.
Auch shikane bietet solch eine Möglichkeit.
Ich glaube zwar, dass es ziemlich egal ist, aber eben darum habe ich nicht groß experimentiert und gleich die Empfehlung genommen.

Nochmal dazu, weshalb überhaupt in diesem Thread gelandet:
Mit den alten Monitoren gab es dieses Problem nicht! Das war halt Glück.
Mit den neuen Monitoren tauchte das Problem auf, hat aber garantiert nichts mit O-Led zu tun, sondern einfach nur mit individuellen Unterschieden (Fertigungstoleranzen?) zweier Monitore des gleichen Typs hinsichtlich der Zeiten für Deep-Standby (quasi off, aber bereit) und wieder Aufwachen. Ich kann das anhand einer OSD-Einblendung schön verfolgen, wo mir gesagt wird, dass kein Signal am DP-x mehr anliegt und dann bei Erwachen dieses wieder gefunden wird. Die Reihenfolge der Einblendung findet sich dann auch bei der Zählweise der Monitore wieder (Monitor 1 - Monitor 2). Dagegen wirkt nun ja shikane, weil es abhängig von DP-1 und DP-2 die Monitore anordnet.
Wenn ich Pech habe, reagiert aber labwc zuvor schon auf eine Situation, die nicht so vorgesehen ist (es soll immer DP-1 UND DP-2 an ihren Plätzen finden). Nachdem shikane das nun in Ordnung gebracht hat, kann ein labwc --reconfigure seine Regeln zum Platzieren der Fenster neu anwenden und das geht ganz gut.

Zwischendurch hatte ich schon mal darüber nachgedacht, die Monitore gezielt nacheinander aufwachen zu lassen, bin aber von diesem Gedanken abgerückt, weil ja dann ebenfalls für labwc eine falsche Situation besteht, wenn nur ein Monitor vorhanden ist. Das hätte mir nicht wirklich weiter geholfen.

 

[pit234a]

Hier ist meine .config/swayidle/config

hier meine:

timeout 300 'wlopm --off \*' resume 'wlopm --on \*'
timeout 1200 'swaylock -f -c 000000'

worauf ich hinaus will: swaymsg gibt es bei mir offenbar nicht. Vermutlich kommt das mit sway?
Der Eintrag störte zwar nicht die Funktion, wurde aber an-gemeckert, weshalb ich dann ohne probierte. Geht bei mir.