Du bist nicht angemeldet.
Xorg bringt folgende Neuerungen mit sich:
Man kann zwischen den Eingabegerätetreibern xf86-input-evdev und xf86-input-libinput wählen.
xf86-input-aiptek erfährt keine Aktualisierung mehr und fliegt aus dem [extra]-Repo, sobald Xorg 1.18.0 dorthin wandert.
Leider funktionieren die aktuellen NVIDIA-Videotreiber nicht mit Xorg-1.18.0. Wer diese also weiterhin verwenden möchte, muss die Aktualisierung von Xorg verhindern, indem entweder
beim pacman-Aufruf die Option --ignoregroup=xorg mitgegeben wird oder
der Eintrag 'xorg' zum Feld IgnoreGroup in der pacman.conf hinzugefügt wird.
EDIT: die propietären Nvidia-Treiber sind wieder einsetzbar.
Offline
Gut, in [testing] … Ich hoffe, die Nvidia-Problematik ist mit dem Übergang nach [core] gelöst …
Offline
Die Meldung verwirrt mich.
Bedeutet dies, dass man innerhalb der Xorg Konfiguration nur entweder den Treiber aus xf86-input-evdev exklusiv oder den Teriber aus xf86-input-libinput benutzen kann?
Laut den Paketinformationen in der Online-Paketsuche stehen die beiden Pakete nämlich auf Paketmanagerebene nicht in Konflikt.
Und was bedeutet das dann für den Praktischen Gebrauch? Kann ich dann nur entweder Maus und Tastatur exklusiv oder einen Touchscreen betreiben?
Das wäre ziemlich Fatal für mich.
MfG
Schard
Installieren kannst du beide, aber welchen Sinn macht es beide parallel einzusetzen (außer zu Testzwecken)? libinput deckt alles ab, was evdev abdeckt, nur noch etwas mehr.
Siehe diesen Blog.
Offline
Also verstehe ich das Richtig, wenn bezüglich der bereitgestellten Treiber gilt:
xf86-input-libinput ⊋ xf86-input-evdev
Dann gäbe es ja keinen Grund, letzteres Paket zu verwenden.
Ich dachte, dass xf86-input-evdev nur die Touch-Systeme abdeckt und xf86-input-libinput die klassischen Eingabegeräte.
Aber das habe ich dann wohl falsch interpretiert.
MfG
Schard
Das neuere Paket erfordert natürlich Umkonfigurationen, und wenn man darauf keinen Bock hat, bleibt man eim alten.
Offline
Betrifft diese Änderung nur die properitären NVIDIA-Treiber oder auch die nouveau-Treiber?
Offline
Betrifft diese Änderung nur die properitären NVIDIA-Treiber oder auch die nouveau-Treiber?
Nur den proprietären Treiber.
Ab wann weiß ich denn, wann die NVIDIA Treiber wieder mit den aktuellen Xorg Treibern laufen?
Update
http://www.geforce.com/drivers/results/95159 sagt, das support hinzugefügt wurde. Aktuell in den Repos ist: 358.16-2.1. Warum ist die Version weiter als die die bei geforce.com angegeben ist?
Beitrag geändert von danbruegge (22.11.2015 13:35:03)
Offline
Ab wann weiß ich denn, wann die NVIDIA Treiber wieder mit den aktuellen Xorg Treibern laufen?
**Update**
http://www.geforce.com/drivers/results/95159 sagt, das support hinzugefügt wurde. Aktuell in den Repos ist: 358.16-2.1. Warum ist die Version weiter als die die bei geforce.com angegeben ist?
Die Frage stelle ich mir auch gerade, da das Update ansteht. Ggf. werd ich's versuchen oder hat es schon jemand durchgeführt!?
Offline
Die Frage stelle ich mir auch gerade, da das Update ansteht. Ggf. werd ich's versuchen oder hat es schon jemand durchgeführt!?
Genau, wegen dem Update frage ich. Da bei mir gerade dieser Fehler geworfen wird:
nvidia-utils: /usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf existiert im Dateisystem
Offline
Dann hast du kein komplettes Systemupdate durchgeführt, mindestens xorg-server ist nicht auf dem aktuellen Stand.
Bis zur Version 1.17.4 gehörte nvidia-drm-outputclass.conf zu xorg-server, seit Version 1.18.0 nicht mehr und befindet sich statt dessen in den nvidia-utils. Wenn xorg-server sich noch auf Versionsstand 1.17.4 befindet kommt es zu dem Konflikt im Dateisystem.
Offline
Update lief durch und bin wieder auf dem Desktop. Gute Arbeit Leute
==> Ausschließlich Paketaktualisierung (neue Ausgabe):
extra/breeze-icons 5.16.0-1 1 -> 2
extra/xf86-input-evdev 2.10.0-1 1 -> 2
extra/xf86-input-keyboard 1.8.1-1 1 -> 2
extra/xf86-input-mouse 1.9.1-1 1 -> 2
extra/xf86-input-synaptics 1.8.3-1 1 -> 2
==> Softwareaktualiserung (neue Version):
core/pacman-mirrorlist 20151115-1 -> 20151122-1
extra/blas 3.5.0-1 -> 3.6.0-2
extra/cblas 3.5.0-3 -> 3.6.0-2
extra/lapack 3.5.0-1 -> 3.6.0-2
extra/nvidia 355.11-4 -> 358.16-2.1
extra/nvidia-libgl 355.11-1 -> 358.16-1
extra/nvidia-utils 355.11-1 -> 358.16-1
extra/xorg-server 1.17.4-2 -> 1.18.0-3
extra/xorg-server-common 1.17.4-2 -> 1.18.0-3
extra/xorg-server-xwayland 1.17.4-2 -> 1.18.0-3
community/virtualbox 5.0.8-2 -> 5.0.10-1
community/virtualbox-host-modules 5.0.8-2 -> 5.0.10-2.1
multilib/lib32-nvidia-libgl 355.11-1 -> 358.16-1
multilib/lib32-nvidia-utils 355.11-1 -> 358.16-1
multilib/lib32-opencl-nvidia 355.11-1 -> 358.16-1
Offline
Dann hast du kein komplettes Systemupdate durchgeführt, mindestens xorg-server ist nicht auf dem aktuellen Stand.
Bis zur Version 1.17.4 gehörte nvidia-drm-outputclass.conf zu xorg-server, seit Version 1.18.0 nicht mehr und befindet sich statt dessen in den nvidia-utils. Wenn xorg-server sich noch auf Versionsstand 1.17.4 befindet kommt es zu dem Konflikt im Dateisystem.
Ja, weil ich die Xorg Gruppe auf Ignore habe. Wegen besagten Problemen mit den Nvidia Treibern.
Update lief durch und bin wieder auf dem Desktop. Gute Arbeit Leute
Super, dann mache ich das auch mal gleich.
Offline
Nach dem Update habe ich ein kleines optisches Problem mit tint2 0.12.3-1:
Mit proprietäre Nvidia Treiber Version 358.16 und Xorg 1.18.0-3.
Nach dem Update habe ich ein kleines optisches Problem mit tint2 0.12.3-1:
https://picload.org/image/pidpldd/screen.jpg
Mit proprietäre Nvidia Treiber Version 358.16 und Xorg 1.18.0-3.
Tritt das Problem auch mit nouveau auf?
Bei mir nicht. Hier habe ich allerdings auch Datum und Uhrzeit nebeneinander.
Offline
Mit nouveau habe ich es noch nicht probiert.
Aber es geht immer noch nicht weg, trotz aktueller Updates.
Also nach dem booten lande ich immer in der Konsole und starte den Desktop mit startx, dabei wird Openbox und tint2 gestartet.
Sehr oft sieht die tint2 Leiste dann so aus:
Dann beende ich Openbox und starte des Desktio erneut mit startx, bis der optische Fehler sich auf den rechten Bereich mit dem Datum und der Uhrzeit beschränkt.
Also normalerweise ist die Leiste einfach nur schwarz.
Mit nouveau habe ich es noch nicht probiert.
Dann tue das mal.
Ich habe das Problem mit tint2 gelöst.
Bisher wurde tint2 über das .xinitrc Script gestartet, so sah das aus:
tint2 &
xbindkeys &
xset s 0 0 &
xset dpms 1800 1800 1800 &
xset -b &
exec openbox
Ich starte nun wie im Arch Wiki angegeben tint2 über den OpenBox Autostart Script unter .config/openbox/autostart
Dazu habe ich den tint2 Eintrag aus dem .xinitrc entfernt und ich musste exec openbox in exec openbox-session ändern, da der autostart file sonst nicht beachtet wird.
Nun gibt es keine Darstellungsfehler.