Läuft das gut? Bei der Beta version gab's angeblich noch Darstellungsfehler im Zusammenhang mit KDE, was mich davon abgehalten hat die Treiber auszuprobieren. Sind die Probleme in der Final beseitigt? Währe schon cool Compiz ohne den blöden XGL laufen zu lassen.
Nein die 9xxxxx Serie ist jetzt stabil und war zuvor Beta. Lässt sich leider aus dem Artikel nicht erkennen, aber jetzt ist es stabil (laut NVIDIA) und die 8xxxx findet man nur noch durch suchen.
Die zusätzliche Querlinie in ksplash? Die ist noch da - aber nicht wirklich störend oder auffällig?
Oder meinst du, daß manchmal Buchstaben defekt sind?
War schon mit den betas ein nicht sehr häufiges Problem und ist bei mir seit dem update nicht mehr aufgetreten. War auch kein 'Darstellungsfehler im Zusammenhang mit KDE', der tritt/trat überall auf.
Ok, hatte irgendwo gelesen, dass genau die von dir beschriebenen Fehler (kaputte Schrift, seltsame Linien) nur unter KDE auftreten und angeblich nicht unter GNOME. Hatte mich zwar gewundert warum das so sein sollte, aber es hatte mich als KDE-User abgeschreckt die Treiber in der Beta-Phase zu installieren. Werde heute Abend mal testen wie der finale Treiber läuft.
Also bei mir lief berryl auch mit dem beta-treiber und KDE problemlos. Manchmal, aber wirklich sehr selten ist emerald aber mal abgestürtzt. Den stable Treiber werd ich mir jetzt gleich mal rauf bügeln
wie lässt man denn beryl ohne xgl laufen? Wenn ich das versuche und beryl starte, dann stürzt sofort der gesamte Desktop ab. Ubuntu Dapper habe ich. Beryl sucht xgl, findet's nicht, sucht nach NVIDIA und dann: zapp! Gibt's wo ein Howto, wie man's macht?
Tja süsser das geht leider nicht! Wenn der XGL-Server nicht läuft und Beryl läuft war es das und du kannst den Xserver abschiessen ;) Du brauchst schon Unbuntu Edgy und musst dort auch den xserver-xgl installieren. Anleitung dafür gibts eigentlich recht viele, direkt für Ubuntu auch in den entsprechenden deutschsprachigen Foren... Einfach mal Googlen
das ist totaler käse. du kannst compiz / beryl auch ohne Xgl laufen lassen.wesentlich für die unterstützung ist die Composite extension und die texture_from_pixmap erweiterung. und das bietet der nvidia treiber auch für sich alleine, er braucht kein AIGLX oder Xgl, lediglich ein aktuelles Xorg7.1!
Von Henning Rogge am Do, 9. November 2006 um 13:51 #
Okay, nochmal langsam...
mit dem 9xxx Treiber von Nvidia brauchst du weder AIGLX noch XGL um Beryl/Compiz zu betreiben. Ich habe bei mir Xorg 7.1 OHNE AIGLX compiliert (weil ich es nicht brauche) und kann Beryl trotzdem benutzen.
Warum ?
Weil der NVidia-Treiber die nötigen OpenGL Befehle direkt (ohne AIGLX/XGL) unterstützt.
hoi zusammen, bin absoluter gentoo-neuling und habe vor ca. 2 wochen gentoo mit xfce4 installiert. habe ne nvidia quadro nvs 110M (so ein mobile teil). damals hab ich alles zum laufen gebracht mit glx. musste noch mal neu installieren und seither bleibt mir beim start von X mit glx das notebook hängen und nix geht mehr. ohne glx kein problem. fragt mich nicht, was ich anders als beim ersten mal gemacht habe.
wie gesagt: jetziger stand: alles läuft, aber wenn ich X mit glx lade -> freeze. braucht man jetzt das glx module der xorg.conf gar nicht mehr zu laden? wie kann ich testen, ob ich trotzdem die 3d unterstüzung habe? das logfile von X gibt zB aus:
....FAILED LOAD GLX module.... (will es ja gar nicht laden...)
weiter unten
... Loading extension NV-GLX NVIDIA 3D Acceleration architecture initialized using the NVIDIA 2D acceleration architecture....
glxinfo und glxgears funktionieren danach natürlich nicht. hab ich trotzdem 3D? direkt von nvidia?
Die noch mit dem 9625 und 9626 gelegentlch aufgetretenen Pünktchen auf einer halbtransparenten (KDE) Konsole gibt es mit dem neuen 9629 nicht mehr.
Wer die Ports für das kleine Experiment mißbrauchen möchte kann in: > /usr/ports/x11/nvidia-driver/ im Makefile die Zeile 83 von: > NVVERSION= 8776 in > NVVERSION= 9629 ändern. Dann ist sind noch die hash Werte und die Größe in der distinfo anzupassen. Benötigt man die Informationen der alten distinfo noch, so bitte diese sichern. Die neuen hash Werte und die Größeninformation für diesen Treiber lässt sich dann mit einem > make makesum erzeugen.
Wie immer alles auf eigene Gefahr. Achtung: rutschig wenn feucht!
Nur leider kein 3D! Nur das, was der OpenSource nv Treiber auch kann.
Also Pustekuchen mit dem 9626 Hier mal ein glxinfo: > name of display: :0.0 > X Error of failed request: GLXBadDrawable > Major opcode of failed request: 144 (GLX) > Minor opcode of failed request: 5 (X_GLXMakeCurrent) > Serial number of failed request: 24 > Current serial number in output stream: 24
glxgears produziert einen coredump. Wie siehts bei anderen Testern aus? Läuft 3D Beschleunigung mit dieser Version? Beim 9625 und 9626 lief 3D einwandfrei.
Ich kann dein Posting bezüglich kein 3D nicht nachvollziehen. Sowohl glinfo als auch glxgears gibt mir sehr akzeptable Werte aus. Beschreib doch mal dein System näher. Vielleicht lässt sich dann daraus der Fehler ableiten.
Linux Kompatibilität ist eingeschaltet in der /etc/rc.conf
Die options COMPAT_FREEBSD5 # Compatible with FreeBSD5 ist in meiner Kernel conf drin.
Letzte Nacht frisch die World und den Kernel gebaut. Zocken mit dem Nvidia Treiber 9626 ging danach noch, hatte nach Neubau mit dem Nvidia Treiber 9626 noch eine Runde ufoai gespielt. :-)
Ich könnte ja einfach downgraden, wieder auf den Nvidia Treiber 9626 zurück, aber die Updatesucht. ;-)
Außerdem hat der brandeue Nvidia Treiber 9629 wirklich einen schicken Splash Screen bekommen. :-D
zander von Nvidia schrieb, das dies ein Problem sei, das sehr ähnlich bei Geforce 2x Karten auftritt und das dies bekannt sei. Es soll in einem zukünftigem NVIDIA FreeBSD Grafiktreiber adressiert werden. > http://www.nvnews.net/vbulletin/showthread.php?t=79791
Also scheint der Nvidia 1.0-9629 FreeBSD Grafikkarten Treiber nicht für Geforce 2 oder Geforce 3 Karten geeignet zu sein!
Danke für das Update! Das habe ich nicht gewusst und muss auch zugeben, mit dem Treiber unter BSD hätt ich dir leider auch überhaupt nicht helfen können. Hoffen wir, dass NVIDIA das im nächsten Release hinbekommt.
Unfortunately, you're hitting a (different) known bug in 1.0-9629 which is triggered during certain types of mode changes (that alot of games use) when using a DFP. The current workaround is to use 1.0-9626 or 1.0-8776. This bug will be resolved in a future driver release.
Will heissen: Kein Upgrade (Livna führt leider auch schon den "gebuggten" 9629 :-(( )
da hast Du mich aber ganz schön verführt, den 9742 auch auszuprobieren. War eine interessante Grenzerfahrung, die netten Coredumps im Kernelmode. :ugly:
Vor allem weil die Wutz von 9742 Kernelmodul sich auch nicht mehr so einfach mit einer Version ersetzen ließ, die auf meiner Kiste bekannt funktioniert. :-O
Es scheint so zu sein, als würde sich die Grenze der Nvidia Legacy Grafikkarten verschieben. Meine Geforce 3 ti 200 scheint beim 9742 zu den Legacy Nvidia Grafikkarten gerutscht zu sein. Während der Treiber zu den Kernelmodulen kopiert wird, nach erfolgreichem passend kompilieren, gibts dann einen Coredump im Kernelmode.
Guckt man dann nach einem genüßlichem fsck in der Paketverwaltung, ist kein Nvidia Treiber installiert. Beim booten nörgelt er aber rum, das er mit der Geforce 3 ti 200 nicht will, der 9742.
Aber seinen Platz will er auch nicht mehr so ohne weiters verlassen, da hat der sich gewehrt und lustig Cordumps im Kernelmode gemacht. War eine nette kleine Herausforderung, den 9742 wieder weg zu bekommen. ;-) (Muß aber auch zugeben das ich den ausgetrickst hatte, weil der 9742 noch nicht mal bauen wollte)
Also kurzum: der 9742 ist nix für Geforce 2 oder 3 Grafikkarten, Finger weg, oder Spaß am basteln!
Angemerkt sei noch, das ich diese lustigen Experimente unter FreeBSD 6.2-PRERELEASE i386 gemacht habe. Aber bisher waren die unterstützeten Grafikkarten bei identischen Treiberversionen von Linux und FreeBSD gleich. Es wäre aber nicht unmöglich, das sich der Treiber unter Linux anders verhält, aber ich, für meinen Teil, habe für heute erst mal genug experimentiert und mag gerade mal nicht mehr rumbooten (nach Coredumps im Kernelmode) ;-)
zumindest ein Anfang =)
http://www.beryl-project.org/
Bitte den Artikel ergänzen!
Währe schon cool Compiz ohne den blöden XGL laufen zu lassen.
http://www.nvidia.com/object/linux_display_archive.html
http://www.nvidia.com/object/linux_amd64_display_archive.html
http://www.nvidia.com/object/freebsd_archive.html
Die zusätzliche Querlinie in ksplash? Die ist noch da - aber nicht wirklich störend oder auffällig?
Oder meinst du, daß manchmal Buchstaben defekt sind?
War schon mit den betas ein nicht sehr häufiges Problem und ist bei mir seit dem update nicht mehr aufgetreten. War auch kein 'Darstellungsfehler im Zusammenhang mit KDE', der tritt/trat überall auf.
Manchmal, aber wirklich sehr selten ist emerald aber mal abgestürtzt.
Den stable Treiber werd ich mir jetzt gleich mal rauf bügeln
wie lässt man denn beryl ohne xgl laufen? Wenn ich das versuche und beryl starte, dann stürzt sofort der gesamte Desktop ab. Ubuntu Dapper habe ich. Beryl sucht xgl, findet's nicht, sucht nach NVIDIA und dann: zapp! Gibt's wo ein Howto, wie man's macht?
Danke,
Martin
Du brauchst mindestens Xorg 7.1, mit Dapper wird das nichts solange Du nicht den Xserver selber kompilierst.
Viele Grüsse!
Susanne
Du brauchst schon Unbuntu Edgy und musst dort auch den xserver-xgl installieren. Anleitung dafür gibts eigentlich recht viele, direkt für Ubuntu auch in den entsprechenden deutschsprachigen Foren... Einfach mal Googlen
Tendenz
mit dem 9xxx Treiber von Nvidia brauchst du weder AIGLX noch XGL um Beryl/Compiz zu betreiben. Ich habe bei mir Xorg 7.1 OHNE AIGLX compiliert (weil ich es nicht brauche) und kann Beryl trotzdem benutzen.
Warum ?
Weil der NVidia-Treiber die nötigen OpenGL Befehle direkt (ohne AIGLX/XGL) unterstützt.
warum geht's dann nicht mit bei mir mit xorg 7.0? Der nvidia-Treiber sollte doch alles bereitstellen, wenn ich Deinen Post richtig lese.
/Martin
"Requirements:
* XOrg 7.1 or later
* NVIDIA graphics drivers >= 1.0-9625
* Any NVIDIA GPU supported by these drivers"
Also verstehe ich Hennings Kommentar nicht! Mit XGL -Aufsatz heisst unter Dapper dann die Devise.
/Martin
wie gesagt: jetziger stand: alles läuft, aber wenn ich X mit glx lade -> freeze. braucht man jetzt das glx module der xorg.conf gar nicht mehr zu laden? wie kann ich testen, ob ich trotzdem die 3d unterstüzung habe? das logfile von X gibt zB aus:
....FAILED LOAD GLX module.... (will es ja gar nicht laden...)
weiter unten
... Loading extension NV-GLX
NVIDIA 3D Acceleration architecture initialized
using the NVIDIA 2D acceleration architecture....
glxinfo und glxgears funktionieren danach natürlich nicht. hab ich trotzdem 3D? direkt von nvidia?
vielen dank für jeden hinweis!
auf einer halbtransparenten (KDE) Konsole
gibt es mit dem neuen 9629 nicht mehr.
Wer die Ports für das kleine Experiment mißbrauchen möchte
kann in:
> /usr/ports/x11/nvidia-driver/
im Makefile die Zeile 83 von:
> NVVERSION= 8776
in
> NVVERSION= 9629
ändern.
Dann ist sind noch die hash Werte und die Größe
in der distinfo anzupassen.
Benötigt man die Informationen der alten distinfo noch,
so bitte diese sichern.
Die neuen hash Werte und die Größeninformation
für diesen Treiber lässt sich dann mit einem
> make makesum
erzeugen.
Wie immer alles auf eigene Gefahr.
Achtung: rutschig wenn feucht!
Gruß, Fusselbär
Nur das, was der OpenSource nv Treiber auch kann.
Also Pustekuchen mit dem 9626
Hier mal ein glxinfo:
> name of display: :0.0
> X Error of failed request: GLXBadDrawable
> Major opcode of failed request: 144 (GLX)
> Minor opcode of failed request: 5 (X_GLXMakeCurrent)
> Serial number of failed request: 24
> Current serial number in output stream: 24
glxgears produziert einen coredump.
Wie siehts bei anderen Testern aus?
Läuft 3D Beschleunigung mit dieser Version?
Beim 9625 und 9626 lief 3D einwandfrei.
Also zu früh gefreut.
Gruß, Fusselbär
Gruß Jan
hier mal ein sysctl -a | grep nvidia:
nvidia 919 1316K - 194658 16,32,64,128,256,512,1024,2048,4096
hw.nvidia.agp.card.rates: 4x 2x 1x
hw.nvidia.agp.card.fw: supported
hw.nvidia.agp.card.sba: supported
hw.nvidia.agp.card.registers: 0x1f000217:0x1f000314
hw.nvidia.agp.status.status: enabled
hw.nvidia.agp.status.driver: nvidia
hw.nvidia.agp.status.rate: 4x
hw.nvidia.agp.status.fw: enabled
hw.nvidia.agp.status.sba: enabled
hw.nvidia.version: NVIDIA FreeBSD x86 Kernel Module 1.0-9629 Wed Nov 1 19:30:26 PST 2006
hw.nvidia.registry.EnableVia4x: 0
hw.nvidia.registry.EnableALiAGP: 0
hw.nvidia.registry.NvAGP: 1
hw.nvidia.registry.EnableAGPSBA: 1
hw.nvidia.registry.EnableAGPFW: 1
hw.nvidia.registry.SoftEDIDs: 1
hw.nvidia.registry.Mobile: 4294967295
hw.nvidia.registry.ResmanDebugLevel: 4294967295
hw.nvidia.registry.FlatPanelMode: 0
hw.nvidia.registry.DevicesConnected: 0
hw.nvidia.registry.RmLogonRC: 1
hw.nvidia.registry.DetectPrimaryVga: 1
hw.nvidia.registry.dwords:
hw.nvidia.cards.0.model: GeForce3 Ti 200
hw.nvidia.cards.0.irq: 19
hw.nvidia.cards.0.vbios: 03.20.02.32.00
hw.nvidia.cards.0.type: AGP
dev.nvidia.0.%desc: GeForce3 Ti 200
dev.nvidia.0.%driver: nvidia
dev.nvidia.0.%location: slot=0 function=0 handle=\_SB_.PCI0.AGPB.VGAG
dev.nvidia.0.%pnpinfo: vendor=0x10de device=0x0201 subvendor=0x1462 subdevice=0x8503 class=0x030000
dev.nvidia.0.%parent: pci2
uname -rsm:
FreeBSD 6.2-PRERELEASE i386
Linux Kompatibilität ist eingeschaltet
in der /etc/rc.conf
Die
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
ist in meiner Kernel conf drin.
Letzte Nacht frisch die World und den Kernel gebaut.
Zocken mit dem Nvidia Treiber 9626 ging danach noch,
hatte nach Neubau mit dem Nvidia Treiber 9626 noch eine Runde ufoai gespielt. :-)
Ich könnte ja einfach downgraden,
wieder auf den Nvidia Treiber 9626 zurück,
aber die Updatesucht. ;-)
Außerdem hat der brandeue Nvidia Treiber 9629 wirklich
einen schicken Splash Screen bekommen. :-D
Gruß, Fusselbär
zander von Nvidia schrieb,
das dies ein Problem sei, das sehr ähnlich bei Geforce 2x
Karten auftritt und das dies bekannt sei.
Es soll in einem zukünftigem NVIDIA FreeBSD Grafiktreiber
adressiert werden.
> http://www.nvnews.net/vbulletin/showthread.php?t=79791
Also scheint der Nvidia 1.0-9629 FreeBSD Grafikkarten Treiber
nicht für Geforce 2 oder Geforce 3 Karten geeignet zu sein!
Zumindest nicht wenn 3D ins Spiel kommt. ;-)
Gruß, Fusselbär
Gruß Jan
Unfortunately, you're hitting a (different) known bug in 1.0-9629 which is triggered during certain types of mode changes (that alot of games use) when using a DFP. The current workaround is to use 1.0-9626 or 1.0-8776. This bug will be resolved in a future driver release.
Will heissen:
Kein Upgrade (Livna führt leider auch schon den "gebuggten" 9629 :-(( )
Kannst ja 9642 ausprobieren...
da hast Du mich aber ganz schön verführt, den 9742 auch auszuprobieren.
War eine interessante Grenzerfahrung, die netten Coredumps im Kernelmode. :ugly:
Vor allem weil die Wutz von 9742 Kernelmodul sich auch nicht mehr so einfach
mit einer Version ersetzen ließ, die auf meiner Kiste bekannt funktioniert. :-O
Es scheint so zu sein, als würde sich die Grenze der Nvidia Legacy Grafikkarten
verschieben.
Meine Geforce 3 ti 200 scheint beim 9742 zu den Legacy Nvidia Grafikkarten gerutscht
zu sein.
Während der Treiber zu den Kernelmodulen kopiert wird,
nach erfolgreichem passend kompilieren,
gibts dann einen Coredump im Kernelmode.
Guckt man dann nach einem genüßlichem fsck
in der Paketverwaltung, ist kein Nvidia Treiber installiert.
Beim booten nörgelt er aber rum,
das er mit der Geforce 3 ti 200 nicht will,
der 9742.
Aber seinen Platz will er auch nicht mehr so ohne weiters verlassen,
da hat der sich gewehrt und lustig Cordumps im Kernelmode
gemacht.
War eine nette kleine Herausforderung, den 9742 wieder weg zu bekommen. ;-)
(Muß aber auch zugeben das ich den ausgetrickst hatte, weil der 9742 noch nicht mal bauen wollte)
Also kurzum: der 9742 ist nix für Geforce 2 oder 3 Grafikkarten,
Finger weg, oder Spaß am basteln!
Angemerkt sei noch, das ich diese lustigen Experimente unter FreeBSD 6.2-PRERELEASE i386
gemacht habe. Aber bisher waren die unterstützeten Grafikkarten bei identischen
Treiberversionen von Linux und FreeBSD gleich.
Es wäre aber nicht unmöglich, das sich der Treiber unter Linux anders verhält,
aber ich, für meinen Teil, habe für heute erst mal genug experimentiert
und mag gerade mal nicht mehr rumbooten (nach Coredumps im Kernelmode) ;-)
Gruß, Fusselbär