staging.inyokaproject.org

Hallo,

ich benutze KDE Plasma mit Xorg.

Wenn ich mein Wacom Tablet einschalte (komplett Netzstrom nicht aus dem Standby) und somit ein weiteres (bekanntes) Display dazu kommt, ändert sich die Farbtemperatur.

Ich habe grundsätzlich die automatische Nachtlicht Steuerung eingeschaltet. Das funktioniert auch sehr gut mit dem Ein- und Ausschalten je bei Auf- und Untergang der Sonne. Jedes Mal wenn das Wacom Display dazu kommt, sehen die Farben aber (unabhängig von der aktuellen Tageszeit) ungefähr so aus, wie sie mitten in der Nacht aussehen sollten.

Hier sind die beiden autorandr Konfiguration für das Display-Setup mit und ohne Wacom.

Konfiguration dual-display:

output DisplayPort-2
off
output HDMI-A-0
off
output DisplayPort-0
mode 3840x2160
pos 0x0
primary
rate 60.00
output DisplayPort-1
mode 3840x2160
pos 3840x0
rate 60.00

Konfiguration dual-display+wacom:

output HDMI-A-0
off
output DisplayPort-0
crtc 0
gamma 1.429:1.0:0.714
mode 3840x2160
pos 0x0
primary
rate 60.00
output DisplayPort-1
crtc 1
gamma 1.429:1.0:0.714
mode 3840x2160
pos 3840x0
rate 60.00
output DisplayPort-2
crtc 2
gamma 1.429:1.0:0.714
mode 1920x1080
pos 7680x0
rate 60.00
transform 2.000000,0.000000,0.000000,0.000000,2.000000,0.000000,0.000000,0.000000,1.000000

Ich bin mir ziemlich sicher, dass das Problem woanders liegt, weil sich die Farben ändern sobald das Wacom Strom bekommt und nicht erst, wenn ich die autorandr Konfiguration lade. Vielleicht wäre es aber möglich, dass Problem über die autorandr Konfiguration zu lösen.

Hier ist noch die Konfigurationsdatei /usr/share/X11/xorg.conf.d/70-wacom.conf

# Some of the below input classes appear 3x times, once for each of
# "tablet", "touchscreen", and "touchpad" to ensure that the Wacom
# driver is not accidentally bound to other types of hardware that
# Wacom has made which are not handled by the wacom driver (e.g the
# Wacom Bluetooth Keyboard)
#
# https://sourceforge.net/p/linuxwacom/bugs/294/

Section "InputClass"
        Identifier "Wacom USB tablet class"
        MatchUSBID "056a:*"
        MatchDevicePath "/dev/input/event*"
        MatchIsTablet "true"
        Driver "wacom"
EndSection

Section "InputClass"
        Identifier "Wacom USB touchscreen class"
        MatchUSBID "056a:*"
        MatchDevicePath "/dev/input/event*"
        MatchIsTouchscreen "true"
        Driver "wacom"
EndSection

Section "InputClass"
        Identifier "Wacom USB touchpad class"
        MatchUSBID "056a:*"
        MatchDevicePath "/dev/input/event*"
        MatchIsTouchpad "true"
        Driver "wacom"
EndSection

Section "InputClass"
	Identifier "Wacom tablet class"
	MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
	MatchDevicePath "/dev/input/event*"
	MatchIsTablet "true"
	Driver "wacom"
EndSection

Section "InputClass"
	Identifier "Wacom touchscreen class"
	MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
	MatchDevicePath "/dev/input/event*"
	MatchIsTouchscreen "true"
	Driver "wacom"
EndSection

Section "InputClass"
	Identifier "Wacom touchpad class"
	MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
	MatchDevicePath "/dev/input/event*"
	MatchIsTouchpad "true"
	Driver "wacom"
EndSection

# Serial Wacom devices should always be one of tablet, touchscreen, or
# touchpad so we can safely get away with just one match section in
# these cases
Section "InputClass"
        Identifier "Wacom PnP device class"
        MatchPnPID "WACf*|WCOM*|WACM*|FUJ02e5|FUJ02e7|FUJ02e9"
        MatchDevicePath "/dev/input/event*"
        Driver "wacom"
EndSection

Section "InputClass"
	Identifier "Wacom serial class"
	MatchProduct "Serial Wacom Tablet"
	Driver "wacom"
EndSection

Section "InputClass"
        Identifier "Wacom serial class identifiers"
        MatchProduct "WACf|FUJ02e5|FUJ02e7|FUJ02e9"
        Driver "wacom"
EndSection

# Hanwang tablets
Section "InputClass"
	Identifier "Hanwang class"
	MatchProduct "Hanwang"
	MatchDevicePath "/dev/input/event*"
	Driver "wacom"
EndSection

# Waltop tablets
Section "InputClass"
	Identifier "Waltop class"
	MatchProduct "WALTOP"
	MatchIsTablet "on"
	MatchDevicePath "/dev/input/event*"
	Driver "wacom"
EndSection

# N-Trig Duosense Electromagnetic Digitizer
Section "InputClass"
	Identifier "Wacom N-Trig class"
	MatchProduct "HID 1b96:0001|N-Trig Pen|N-Trig DuoSense"
	MatchDevicePath "/dev/input/event*"
	Driver "wacom"
	Option "Button2" "3"
EndSection

# Dell Canvas 27 (touch part is an Advanced Silicon, pen part a Wacom)
Section "InputClass"
        Identifier "Dell Canvas 27 Touch"
        MatchUSBID "2575:0204"
        MatchDevicePath "/dev/input/event*"
        MatchIsTouchscreen "true"
        Driver "wacom"
EndSection

# Surface Go
Section "InputClass"
        Identifier "SurfaceGo Touch"
        MatchProduct "ELAN9038:00 04F3:261A"
        MatchDevicePath "/dev/input/event*"
        Driver "wacom"
EndSection

# Nuvision Solo 10 Draw (Supports Surface Pens)
Section "InputClass"
        Identifier "Nuvision Solo 10 Draw"
        MatchProduct "04F3200A:00 04F3:22F7"
        MatchDevicePath "/dev/input/event*"
        Driver "wacom"
EndSection

Gruß

Extrawunsch (optional): Generell finde ich das je mit der automatischen Nachtlicht-Steuerung auf meinen Hauptmonitoren ganz nett aber am liebsten wäre es mir, wenn auf dem Wacom die Farben zu jeder Tageszeit so echt wie möglich dargestellt werden würden.

Hallo!

Ich kann mit dem Tablet wenig anfangen, es scheint zwar „nicht mit Linux kompatibel zu sein“, aber es gibt/gab sehr viel Arbeit im Kernelmodul. Scheinen also viele zu verwenden.

Abseits davon:

…weil sich die Farben ändern sobald das Wacom Strom bekommt…

Prüfe mittels udevadm, was da ausgelöst wird. Möglicherweise wird dort automatisch eine Einstellung geladen, die das Farbprofil ändert oder ähnliches. Da müsstest du dann auch Ansetzen, um das zu unterbinden.

Was auf jeden Fall stattfindet ist eine „Neukonfiguration“ von Plasma, da dieses bei angeschlossenen weiteren Monitoren entsprechende Settings für diese lädt (wenn vorhanden). Diese Dateien liegen unter ~/.local/share/kscreen/ in der JSON vor und stellen alle bekannten Konstellationen dar.

Vielen Dank schon mal für den Hinweis. Ich werde mal udevadm monitor laufen lassen und das Tablet an und ausschalten.

Wichtige Hinweise, die womöglich in eine andere Richtung führen: Beim Laden der Konfiguration ohne Wacom mit autorand wurden die Farben wieder normal obwohl das Wacom noch angeschaltet war.

Hier noch mal der Verlauf meiner Beobachtungen in Stichworten

• Computer mit zwei Monitoren und ausgeschaltetem Wacom gestartet. Farbtemperatur ist im Tag-Modus

• Wacom wird an Strom angeschlossen > Farbtemperatur schaltet um auf Nacht-Modus obwohl Tag ist

• Wacom (war nach dem Anschließen noch im Standby) wird eingeschaltet > Keine Änderung der Farbtemperatur

• "autorandr --load dual-display+wacom" > Keine Änderung der Farbtemperatur

• ...

• "autorandr --load dual-display" > Farbtemperatur wechselt wieder auf Tag-Modus

• "autorandr --load dual-display+wacom" > Farbtemperatur wechselt auf Nacht-Modus

• ...

• Sonnenuntergang (Wacom ist immer noch aktiv) > Farbtemperatur wechselt wieder auf Tag-Modus (anscheinend beginnt der graduierliche Wechsel zum Nacht-Modus)

• "autorandr --load dual-display" > Keine Änderung der Farbtemperatur

• "autorandr --load dual-display+wacom" > Keine Änderung der Farbtemperatur

Das Ausführen von autorandr löst keine Meldungen in udevadm monitor aus.

Es macht auf mich schon deutlich den Eindruck, als wenn eine Änderung der Monitor-Konfiguration unter bestimmten Bedingungen einen Fehler in der Verwaltung des Tag-/Nacht-Modus auslöst.

Ich habe mir auch alle JSON Dateien unter ~/.local/share/kscreen/ angesehen, konnte darin aber nicht verdächtiges finden.

Woher hast du denn dieses autorandr? Vielleicht löst das ja auch das Verhalten aus, da scheinen einige Hooks & Co möglich zu sein. Ich weiß auch nicht, ob das NightColor unter X11 schon 100% funktioniert, das wurde meine ich erst mit Plasma 5.24 oder so von Wayland portiert.

Du kannst ja mal einen frischen Nutzer anlegen, diesen mit Plasma (Wayland) starten und das Verhalten beobachten.

Ansonsten warten auf 5.27, da wurde Multimonitor komplett neu geschrieben um die jahrelangen Probleme in den Griff zu bekommen.

Ich kann das mal mit einer Wayland-Session ausprobieren. Vielen Dank für den Hinweis.

Grundsätzlich hatte ich Wayland schon mal getestet und ich weiß nicht mehr genau was es war aber irgendwas habe ich da nicht so hinbekommen wie ich es haben wollte. Im Moment habe ich zumindest nicht die Zeit um komplett auf Wayland umzusteigen.

autorandr ist so ein Paket das von Debian übernommen wurde. Ich kann Dir nicht genau sagen, wie alt der Befehl schon ist. Seit ein paar Jahren ist das ein python script (wenn ich mich richtig erinnere war das früher mal Perl) das auf x11-xserver-utils aufbaut.

-

Ich glaube, dass ich dass das Grafik-Tablet zuletzt Nachts angeschaltet war. Ich weiß nicht genau, wie die Nachtlicht-Steuerung unter Plasma mit X11 arbeitet aber rein hypothetisch wäre doch auch folgende Annahme nicht ganz unplausibel:

Angenommen, der Tag-/Nacht-Modus wäre ein Dienst der nur beim Start des Computers sowie zum Auf- und Untergang der Sonne (bzw. eine Weile davor und danach wegen des fließenden Übergangs) die Farbtemperatur ändern. Ebenfalls angenommen, die Farbtemperatur wird nicht global sondern nur für die aktuelle Monitor-Konfiguration gespeichert. Falls dann die Nachtlicht-Steuerung nicht auf einen Wechsel der Monitor-Konfiguration reagieren würde, müsste es doch zwangsläufig zu dem von mir beobachteten Problem kommen, wenn z.B. am Tag auf eine Monitor-Konfiguration gewechselt wird, die zuletzt in der Nacht aktiviert war.

autorandr ist noch nicht ideal aber eine relativ gut funktionierende Lösung.

Ich mag es nicht, dass der Computer sofort reagiert, wenn er ein neues Anzeigegerät erkennt. Ich habe meinen Fernseher grundsätzlich angeschlossen aber ich möchte, dass die Anzeige auf dem Fernseher nur manuell aktiviert werden kann und nicht automatisch, sobald der Fernseher angeschaltet wird.

Mit Autorandr kann man Anzeige-Konfigurationen speichern und dann später wieder laden. Ich kann aber in den gespeicherten Konfigurationen nichts verdächtiges finden, was die Farbtemperatur enthält. Außerdem trat der Fehler in der Farbtemperatur ja auch schon auf, bevor ich autorandr ausgeführt habe.

bugblatterbeast schrieb:

autorandr ist so ein Paket das von Debian übernommen wurde…

Dann ist es sicherlich ratsam zunächst eine aktuelle Version zu nutzen: phillipberndt/autorandr. Da sind auch einige Plasma-spezifische Dinge geändert. Vielleicht hilfts.

Angenommen, der Tag-/Nacht-Modus wäre ein Dienst…

Ich glaube so intelligent ist die Mechanik nicht. Soweit ich mich erinnere wird da nur in Intervallen eine Prüfung laufen gelassen und bei Bedarf der Filter angepasst. Theoretisch könnte das natürlich so sein.

Ich mag es nicht, dass der Computer sofort reagiert, wenn er ein neues Anzeigegerät erkennt…

Damit begeben wir uns jetzt in für mich unklare Gewässer. Wenn du einen Monitor anschliesst, ein- oder ausschaltest, etc. dann wird von der Grafikkarte eine entsprechende Information ans System gesendet („Neuer Monitor“ in den meisten Fällen). Kommt aber auch sehr auf die Karte, den verfügbaren Treiber im Zusammenspiel mit der Karten-Firmware (alle proprietär) und dem verwendeten Anschluss (DP,HDMI,DVI,VGA) an. Soweit die grobe Theorie.

Bei Plasmas KWin läuft dann einiges ab, udev zum ermitteln der verschiedenen GPU, DRM-Backend, Mode Setting, OpenGL Backend, EGL Backend,… An der Stelle bin ich aber raus, das ist mir zu hoch und weitab von dem, was mich interessiert.

Plasma ist bewusst auf Dynamik ausgelegt, insofern dürfte es schwer sein genau den Teil (ohne Probleme) zu deaktivieren. Du könntest allerdings KScreen deaktivieren (Systemsettings → Startup and Shutdown → Background Services → KScreen 2), das schneidet einen Teil der Dynamik schon ab. Als weitere Möglichkeit bliebe noch Plasma mit openbox anstatt KWin zu verwenden.
Wenn du nicht auf dynamisches Reagieren stehst, dürfte Plasma aber generell die falsche Wahl sein. Ein Bärenanteil dessen was über den D-Bus läuft dient dazu Änderungen an alle laufenden Programme zu übermitteln.

Plasma ist bewusst auf Dynamik ausgelegt, insofern dürfte es schwer sein genau den Teil (ohne Probleme) zu deaktivieren.

Das ist völlig OK. Ich wollte nur erklären, warum ich ein Tool wie autorandr benötige. Ich kann damit Display-Konfigurationen speichern und muss nicht nach jeder Änderung wieder alles einstellen. Ich bin im Moment (abgesehen von der Farbtemperatur) zufrieden.

Es war auf jeden Fall ein sehr guter Hinweis, die neueste Version von autorandr auszuprobieren. Ich habe die Profile noch mal neu überschrieben und jetzt werden mehr Werte als vorher gespeichert. Anscheinend auch Informationen über die Filter. Theoretisch müsste jetzt zumindest festgelegt sein, dass die Farbtemperatur immer im Tag-Modus ist, wenn ich eins meiner autorandr Profile lade. Das werde ich zu später Stunde mal ausprobieren.

Es ist jetzt wie erwartet: wenn ich jetzt eines der autorandr Profile lade ist zumindest immer Tag-Modus. Damit kann ich leben.

Bedeutet, das autorandr NightColor beeinflusst? Dann müsstest du das ja auch konfigurieren können (oder beantragen). Ich mag das gar nicht, wenn mir Abends ein Programm die Netzhaut wegbrennt 😉