Ich habe noch den nvidia-Hauptartikel angepasst, damit irgendjemand auch die Seite verlinkt. ☺ Danke fürs Verschieben.
Gruß Dee
Anmeldungsdatum: Beiträge: 20087 Wohnort: Schwabenländle |
Ich habe noch den nvidia-Hauptartikel angepasst, damit irgendjemand auch die Seite verlinkt. ☺ Danke fürs Verschieben. Gruß Dee |
||
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Bitte mal über den neuen Punkt Kein VSync bei GeForce-Karten der 600er-Reihe drübergucken. Danke! |
||
Anmeldungsdatum: Beiträge: 642 |
Vorbildlich, perfekt; da kommt Freude auf, wenn von diesem Bug geplagt. 👍
Ja. Die Aussage "Wenn diese Zeile in der Datei vorkommt, wird der "nvidia"-Treiber geladen." ist nur schlicht falsch, da -falls Ärger mit dem Kernelmodul- ein paar Zeilen später üblicherweise die Zeile (II) Unloading /usr/lib/x86_64-linux-gnu/xorg/extra-modules/nvidia_drv.so folgt und der User dann vor VESA sitzt. Natürlich würde auch die Unloading-Zeile gegrept werden, was aber an der falschen Aussage nichts ändert. Edit: Alternativ könnte man auch einfach
nehmen, dann ist der Treiber auch tatsächlich geladen. |
||
Anmeldungsdatum: Beiträge: 17331 Wohnort: /home/noise |
Evtl. kann jemand auch einen aktuellen Screenshot beisteuern. ☺ |
||
Anmeldungsdatum: Beiträge: 275 |
hi! V for Vortex! Eine hochinteressante Änderung im Artikel. Sag mal, tritt das Verhalten eigentlich bei allen aktuellen Treiber auf oder nur bei bestimmten Versionen? Eine Ergänzung dahingehend fände ich wertvoll. Siehe auch Nvidia-Changelog 331.38 🇬🇧. Solche Angaben erhöhen die Pflegbarkeit des Wikis ungemein. ☺ Bitte jetzt nicht als Kritik, sondern eher als Anregung verstehen. Danke. 😉 Evtl. ist sowas ja auch schnell 'Geschichte' . Ausgehend davon, dass der Fehler auch bei Nvidia bekannt ist und daran gearbeitet wird/wurde. Von MESA will ich in dem Zshg. mal ruhig sein. @march: Der Screenie gilt nach wie vor für 12.04, bis zu dessen Supportende. Falls Du den von neueren Ubuntu-Versionen meinst, den findet sich in Ungültiges Makro restricted-manager (Verwaltung eingeschränkter Treiber). Über Bild-Redundanz im Wiki wurde ja noch nie gesprochen *lach* Hoffentlich wird das nie ein Thema... Genial wäre eine gemeinsame Datenbank...
Dieses Makro ist nicht verfügbar |
||
Anmeldungsdatum: Beiträge: 17331 Wohnort: /home/noise |
Es geht um das Theme - wir versuchten schon 2011? das alte braune Theme zu entfernen und gegen aktuelle Screenshots zu tauschen... Es gab dazu auch einen Aufruf.
Danke. ☺
Redundanzen sind böse. Bei Bildern ist es doch etwas anderes. Falls in einem Artikel ein Bild gelöscht wird oder ein Artikel ins Archiv wandert kann es passieren, dass Bilder in anderen Artikeln fehlen. Da dies in der Vergangenheit schon einige Male passiert ist... ☺ |
||
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Genau so habe ich das verstanden, keine Sorge und danke. ☺ Das Problem tritt bei mir unter Ubuntu 12.04 mit der Treiberversion 319.32 auf. Neuere Versionen habe ich nicht getestet. Allerdings steht im von mir am Ende des ersten Absatzes als Quelle verlinkten Thread im Nvidia-Entwicklerforum,
gefolgt vom Originaltext der Antwort Plattners, eines Entwicklers des Nvidia-Linuxtreibers. Das klingt leider nicht sehr danach, als würde es in absehbarer Zeit (oder überhaupt) durch ein Treiberupdate behoben werden – ob nun wegen des unberechenbaren Timings (laut Plattner) oder anderen Gründen, wie sie manche Leute auf devtalk.nvidia.com Plattner unterstellen. Es wäre toll, wenn es jemand mit einer GeForce 6xx/7xx/Titan mit Kepler-Chipsatz mal mit dem neuesten Nvidia-Treiber testen könnte. edit: Kommenden Mai/Juni kann ich evtl. selbst etwas dazu sagen, weil ich dann wahrscheinlich auf die nächste LTS 14.04 wechsle oder sie zumindest testweise neben der 12.04 installiere. Gibt es in dem von Dir verlinkten Changelog einen bestimmten Eintrag, der Dich hoffen lässt, oder wolltest Du nur auf die aktuelle Version hinweisen? Ich habe in der Liste nichts passendes gefunden, stecke aber auch nicht sehr tief in Grafiktreiber-Technik drin. 🐸 |
||
Anmeldungsdatum: Beiträge: 642 |
Installiere Dir doch schnell den Treiber (eg. xorgedgers PPA), Sache von Minuten... Schlage vor, den Abschnitt ganz oben bei den Problemlösungen zu platzieren, da ja quasi jede aktuelle GPU betroffen. |
||
Anmeldungsdatum: Beiträge: 275 |
Dann schreib's doch explizit rein, es wird sich nicht unbedingt jeder einen 10 Seiten langen externen Forenbeitrag durchlesen. Wobei es natürlich ideal wäre, den genauen LTS-Enablement-Stack zu benennen. In Pkto. Grafik gibt's da schon Unterschiede.
Eigentlich alle, bis auf die Anpassung an XServer 1.15, das ist genauso Zukunftsmusik wie OpenGL 3.0 – Wenn es wirklich mit dem Timing zu tun hat, würde ich es sogar mal mit dem Mainline-Kernel probieren. Ich benutze seit einer Weile nur noch Mainline, es werden mMn einfach zu wenig Änderungen durchgereicht. Das steht aber auf einem anderen Blatt. Zu der ganzen Problematik ist aber vermutlich nur das neue G-sync Monitor-Modul (Artikel bei heise.de) die
Nö, bin eigentlich kein "Versionsjunkie" , falls Du das meinst. 😉
Mach doch! Es könnte im ganzen Wiki so sein, dann wäre die Suche leichter. Ich finde Deinen Vorschlag sehr sinnvoll. Spannend wird das Ganze ja dann nochmal, wenn Nouveau Compositing gelernt hat. |
||
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Sorry, da mir persönlich der Workaround reicht, werde ich nicht nur um des Testens Willen neue Treiber aus Fremdquellen installieren.
Ich sehe die Notwendigkeit dazu nicht. Wenn jemand dieses Problem hat, wird im Wiki ein Workaround beschrieben. Wenn nun jeder mit diesem Problem seine Treiberversion dazuschreibt, führt das nur zu einem unübersichtlichen Versionswald. Zudem lässt die Aussage des Nvidia-Entwicklers einen treiberseitigen Fix unwahrscheinlich wirken, zudem das Problem auch unter Windows auftritt. Aber ich bin vor allem Wiki-Nutzer und seltener Wiki-Schreiber, und stecke daher nicht so tief in den Wiki-Regeln und -Gepflogenheiten drin. Was meinen denn die Wiki-Veteranen hier dazu?
Das ist m.E. zu vage, um nicht wie ein pauschales „neuer ist besser“ zu klingen. Bitte konkreter: Welche Neuerungen der v331.38 haben Deines Erachtens welchen Einfluss auf welche vermutlichen Ursachen des beschriebenen Problems? |
||
Anmeldungsdatum: Beiträge: 3 |
Hallo zusammen, Habe gerade eine Sektion zum Laden einer falschen libglx.so erstellt. Dieses Problem ist bei mir seit Ubuntu 8.04 vorhanden und bedingt mein ständiges Wechseln zwischen dem nvidia und dem nouveau-Treiber: wenn ich genug davon habe, die Links bei jedem MESA-Update an zu passen, wechsle ich zu nouveau, bis es mich zu sehr stört, dass ich keinen suspend-to-ram und suspend-to-disk nutzen kann (und andere Probleme habe, etwa plötzliche Abstürze) und wieder wechsle. Trotz langer Suche habe ich keine strukturelle Lösung gefunden, weil ich nirgendwo Informationen darüber finde, in welcher Reihenfolge Xorg nach Modulen sucht. Ich habe jetzt einen strukturellen Lösungsansatz gepostet, aber vielleicht kann das ja jemand anpassen, der X besser kennt als ich einfacher Langzeitnutzer. Schöne Grüße, Philippe |
||
Ehemaliger
Anmeldungsdatum: Beiträge: 28954 Wohnort: WW |
Hallo, Danke für die Ergänzung & Willkommen bei ubuntuusers.de ☺ Den Teil der "strukturellen Lösung" habe ich erst Mal gelöscht - wie ja im Text stand war, war die Lösung ungetestet. Von daher gehört die auch nicht ins Wiki. Wenn du das getestet hast und es funktioniert kann das dann gerne ins Wiki! In der "schnellen Lösung" habe ich ein bisschen Syntax und so korrigiert. Und den "useless use of cat" eliminiert 😉 Gruß, noisefloor |
||
Anmeldungsdatum: Beiträge: 275 |
Hallo üblicherweise kann Jockey/ubuntu-drivers-common (s.restricted-manager) die Treiber laden/entladen, ohne sie zu entfernen. Und das sogar auf Kommandozeilen-Ebene. edit: Das ist der von Ubuntu empfohlene Standard-Weg auf der grafischen Oberfläche. Ohne jetzt mehr System-Hintergründe zu kennen, würde ich vermuten, dass es sich um ein individuelles Problem handelt. (Zitat: Besteht seit 8.04 ...) |
||
Anmeldungsdatum: Beiträge: 642 |
|||
Anmeldungsdatum: Beiträge: 3 |
Hallo zusammen! zzippi: Jedenfalls ist der Fehler bei mir systematisch... nettoerzählt: ich habe das Problem in der Vergangenheit beim Benutzen von jockey gehabt, dieses Mal habe ich es durch ein einfaches installieren über dselect gemacht (wenn ich an X herum bastele, dann benutze ich keine graphischen Tools noisefloor: Ich habe es jetzt getestet, indem ich die libglx.so von MESA wieder an ihren Platz gebracht habe und die Symlinks, die ich überall verstreut habe wieder gelöscht habe. Mein Xorg.0.log sagt mir brav: philippe@saaba:~$ cat /var/log/Xorg.0.log | grep libglx [ 1436.173] (II) Loading /usr/lib/nvidia-319-updates/xorg/libglx.so Sorry für das cat, aber das habe ich eben so gelernt... ☺ Von mir aus können wir also die strukurelle Lösung behalten und die quick and dirty-Lösung in die Tonne hauen... |