X.org Update: Tester gesucht

Yamagi

Possessed With Psi Powers
Teammitglied
Das FreeBSD X.org-Team sucht Tester für ein großes X.org-Update. Dies ist das erste Update seit langer Zeit und wird wahrscheinlich die entsprechend zerstörerischen Auswirkungen haben. Die größten Änderungen gegenüber dem derzeitigen Zustand sind:

- xf86-video-nouveau wurde entfernt. Stattdessen sollte x11/nvidia-driver genutzt werden.

- Die Unterstützung für KMS und GEM ist auf Seite der Ports nun Teil des Systems.

- Es lebt eine alte X.org-Version (für Intel-Nutzer ohne KMS und GEM) gemeinsam mit einer neuen Version (für Intel-Nutzer mit KMS und GEM) im Portstree. Die beiden make.conf-Variablen "WITH_NEW_XORG" und "WITH_KMS" kontrollieren dies.

Alles weitere steht in der E-Mail:
Code:
Knock knock...

The X11 Team is pleased to announce the next round of Xorg updates.
Note that this is experimental so you really have to know what you are
doing, read UPDATING in the repository, and follow our exact
instructions. We are specifically looking for feedback from Intel, ATI
and NVIDIA users.

Summary of changes:

xf86-video-nouveau has been removed along with the WITHOUT_NOUVEAU
knob. We suggest switching to the nvidia blob. 

KMS Support [1]:
Unfortunately, the intel KMS driver will only work for the latest
FreeBSD 9-STABLE or 10-CURRENT users. The patch for HEAD current is
named all.13.1.patch. The higher the version the newer the patch is.
Other needed patches are already available in the Xorg update.

HEAD Users:
Get the latest patchset from Kib here: 
http://people.freebsd.org/~kib/drm/

9-STABLE Users: 
'meowthink' is currently maintaining the backport to 9 STABLE.
Make sure you have the latest FreeBSD 9-STABLE source.
Get the patch from here:
https://docs.google.com/leaf?id=0BxbPi2OX4_B-NWY3NWU3MzEtNDBjYy00NTljLThlZGItMWFlYjIyYjI4Yjk3&hl=en_US

Rebuild your Kernel and reboot.

Known issuse:
There will be a patch reject in the sys/dev/drm/i915_suspend.c file.
The solution is to manually undo the expansion of the $FreeBSD: ....$
tag, so it only saysis $FreeBSD$.

Checkout Xorg Development Repo:
You will need to install devel/subversion in order to checkout the xorg
repo. Next, you will need to add WITH_NEW_XORG=yes in
your /etc/make.conf if you want to try out the new Xorg and mesa.

Intel users: note that if you are not qualified for the KMS patch, you
shouldn't use WITH_NEW_XORG=yes because the old intel driver doesn't
build with the new X server. If you are qualified, you should also set
WITH_KMS=yes in /etc/make.conf. 

svn co https://trillian.chruetertee.ch/svn/ports/tags/xorg_7_5_2

A small merge script to merge the svn checkout into the real portstree
can be found here:

http://people.freebsd.org/~miwi/xorg/xorgmerge

The script is a modified version of the old kdemerge script. Please set
the KDEDIR variable to the path of your X.org ports.

After merging, run one of the following command, depending on which
tool you use to manage your installed packages.

    portupgrade -af \*
    portmaster -a

After installing these, you will have to rebuild all xf86-* ports. We
will bump all related ports during the commit to the ports tree.

Roadmap:

Our current plan is to let the CFT running until the last weekend of
February. We hope to get a lot feedback to solve as many problems as
possible. So please help us to get the best xorg update ever in!


Links:
http://wiki.freebsd.org/Intel_GPU [1]
http://wiki.freebsd.org/Xorg
http://miwi.bsdcrew.de/2012/02/working-on-xorg-stuff/

Your FreeBSD Xorg Team

PS: Please reply to the x11@ mailing list. Cross posted due to the
potentially disruptive nature of the change and need to get a wide
variety of testers.

-- 
+------------------oOO--(_)--OOo----------------+
With best Regards,
        Martin Wilke (miwi_(at)_FreeBSD.org)
 
Habe ich das richtig verstanden, dass der neue Port überhaupt nur von Intel und (prop.) Nvidia Usern genutzt werden kann, da für die AMD-Treiber eben noch TTM fehlt?

Oder funktionieren die klassischen Treiber weiterhin mit dem neuen Xorg und ich profitiere vielleicht von Bugfixes, neuerem DRM etc?
 
Habe ich das richtig verstanden, dass der neue Port überhaupt nur von Intel und (prop.) Nvidia Usern genutzt werden kann, da für die AMD-Treiber eben noch TTM fehlt?

Oder funktionieren die klassischen Treiber weiterhin mit dem neuen Xorg und ich profitiere vielleicht von Bugfixes, neuerem DRM etc?

Es gibt einige ATI Karten wo der DRM/KMS code funktioniert. Darum machen wir unteranderem einen CFT um sachen wie diese raus zu finden.
 
Das Wiki klingt ein wenig entmutigend, sehr frickelig und experimentiell das Ganze. Kommt da noch was?
Selbst phoronix hat dem wieder einen Artikel gewidmet.

Selbstverstaendlich kommt dort noch was, der Treiber ist Experimentel aber trotzdem sehr weit vorran geschritten. Darum haben wir im X11@ Team beschlossen den CFT public zu machen und kib mehr zu helfen. Der CFT witmet sich nicht _NUR_ ATI, Intel oder Nvidia users, es gibt besseres 3D rendering mit der neuen mesa version. Irgendwie muessen wir ja auch User bedienen die auf neuere versionen warten weil dort unter anderem Karten funktionieren die nicht auf KMS, GEM oder TTM zurueck greifen. Wir wissen das wir speziell nouveau user vor dem kopf stossen, aber zumindest haben sie alternativen wo mit sie leben koennen.
 
Allerdings könnt ihr auch argumentieren, dass Nouveau vor allem ideologisch begründet ist und keinesfalls technisch. Ein absoluter Großteil der Nutzer wird mit dem Blob gut bedient, außen vor bleiben müssen eigentlich nur zwei Gruppen:
- Nutzer von Hardware vor der GeForce 6 Generation
- Nutzer Abseits von x86 und amd64
Beide Gruppen dürften sehr klein sein, weshalb es in meinen Augen durchaus gerechtfertigt ist dort einige Nachteile in Kauf zu nehmen, wenn es denn dafür auf der anderen Seite mit KMS und GEM vorangeht. Denn dort ist im Moment nicht nur die größte Baustelle, sondern auch das größte Potential.
 
Mich juckt es in den Fingern, das ist ein wichtiger Schritt für FreeBSD. Aber ich habe etwas Angst um meine Produktivsysteme.

Na ja, bei der Tinderbox ist X ja nicht so wichtig, da werde ich es vielleicht versuchen.
 
Es gibt einige ATI Karten wo der DRM/KMS code funktioniert. Darum machen wir unteranderem einen CFT um sachen wie diese raus zu finden.

Danke für die Info, Miwi! Ich werde mich Donnerstag mal ranmachen (nachdem ich pkgng nutze, kann ich mangels aktueller PKGSITE ja sowieso keine Pakete mehr installieren :rolleyes: ).

Die richtige Vorgehensweise für ATI wäre dann
WITH_NEW_XORG=yes
aber kein
WITH_KMS=yes
richtig?

Sobald ich Zugang zum FTP habe, könnte ich dann auch hier Pakete für AMD64 bereitstellen.+

edit: Sind reguläre X-Anwendungen kompatibel zu beiden Xorg-Versionen? Also reicht es die xorg-Ports neuzubauen? Dann könnte ich im Zweifel die alten Pakete zurückspielen, wenn was schief geht. Ansonsten muss ich so gut wie alles neubauen, oder?
 
Ein Vorteil von Nouveau bzw. pscnv: OpenCL nativ.
(Und außerhalb von FreeBSD und x86 ist nur Nouveau eine Alternative, nv kann man größtenteils vergessen. Mein Desktop weint derweilen.)
 
Danke für die Info, Miwi! Ich werde mich Donnerstag mal ranmachen (nachdem ich pkgng nutze, kann ich mangels aktueller PKGSITE ja sowieso keine Pakete mehr installieren :rolleyes: ).

Die richtige Vorgehensweise für ATI wäre dann
WITH_NEW_XORG=yes
aber kein
WITH_KMS=yes
richtig?

Sobald ich Zugang zum FTP habe, könnte ich dann auch hier Pakete für AMD64 bereitstellen.+

edit: Sind reguläre X-Anwendungen kompatibel zu beiden Xorg-Versionen? Also reicht es die xorg-Ports neuzubauen? Dann könnte ich im Zweifel die alten Pakete zurückspielen, wenn was schief geht. Ansonsten muss ich so gut wie alles neubauen, oder?

jo
 
h^2 schrieb:
Danke für die Info, Miwi! Ich werde mich Donnerstag mal ranmachen (nachdem ich pkgng nutze, kann ich mangels aktueller PKGSITE ja sowieso keine Pakete mehr installieren ).

Die richtige Vorgehensweise für ATI wäre dann
WITH_NEW_XORG=yes
aber kein
WITH_KMS=yes
richtig?

Sobald ich Zugang zum FTP habe, könnte ich dann auch hier Pakete für AMD64 bereitstellen.+

edit: Sind reguläre X-Anwendungen kompatibel zu beiden Xorg-Versionen? Also reicht es die xorg-Ports neuzubauen? Dann könnte ich im Zweifel die alten Pakete zurückspielen, wenn was schief geht. Ansonsten muss ich so gut wie alles neubauen, oder?

jo

Sorry fürs Nachboren, kannst du bei dem letzten entweder oder noch konkretisieren, auf was sich das "jo" bezieht? Wenn alles neugebaut werden muss, würde ich das doch eher verschieben...
 
Ich bekomme noch mehr rejects bei einem aktuellen 9-STABLE:
Code:
# patch < /tmp/drm-all.13.0-stable9.1.patch -N 2>&1 | grep -i failed -B 5
|diff --git a/stable/9/sys/modules/drm/drm/Makefile b/stable/9/sys/modules/drm/drm/Makefile
|--- a/stable/9/sys/modules/drm/drm/Makefile    (revision 230124)
|+++ b/stable/9/sys/modules/drm/drm/Makefile    (working copy)
--------------------------
Patching file Makefile using Plan A...
Hunk #1 failed at 8.
1 out of 1 hunks failed--saving rejects to Makefile.rej
--
|diff --git a/stable/9/sys/modules/drm/i915/Makefile b/stable/9/sys/modules/drm/i915/Makefile
|--- a/stable/9/sys/modules/drm/i915/Makefile   (revision 230124)
|+++ b/stable/9/sys/modules/drm/i915/Makefile   (working copy)
--------------------------
Patching file Makefile using Plan A...
Hunk #1 failed at 2.
1 out of 1 hunks failed--saving rejects to Makefile.rej
--
|--- a/stable/9/sys/vm/device_pager.c   (revision 230124)
|+++ b/stable/9/sys/vm/device_pager.c   (working copy)
--------------------------
Patching file sys/vm/device_pager.c using Plan A...
Hunk #1 succeeded at 204 (offset 128 lines).
Hunk #2 failed at 251.
Hunk #3 failed at 376.
2 out of 3 hunks failed--saving rejects to sys/vm/device_pager.c.rej
Was muss ich da tun?

edit: mit patch -p3 verschwinden zwei der fails. Der dritte wurde manuell eingepflegt. Jetzt bekomme ich beim Bauen:
Code:
[...]/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:4774: error: redefinition of 'drm_gem_name_create'
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:132: error: previous definition of 'drm_gem_name_create' was here
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:4798: error: redefinition of 'drm_gem_names_delete_name'
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:4587: error: previous definition of 'drm_gem_names_delete_name' was here
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:4809: error: redefinition of 'drm_gem_names_remove'
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:167: error: previous definition of 'drm_gem_names_remove' was here
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:4828: error: redefinition of 'drm_gem_names_foreach'
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_gem_names.c:186: error: previous definition of 'drm_gem_names_foreach' was here
 
Zuletzt bearbeitet:
Verfolgst du freebsd-x11?

Ich bin zur Zeit folgendes am Testen (baue gerade die Welt)

  1. Quellen vom aktuellen 9-STABLE mittels svn beziehen
  2. Code:
    # sed -i -e 's/FreeBSD: src.*Exp /FreeBSD/' /usr/src/sys/dev/drm/i915_suspend.c
    http://lists.freebsd.org/pipermail/freebsd-x11/2012-February/011481.html
  3. Code:
    # patch -p3 < /path/to/drm-all.13.1-stable9.1.patch
    http://lists.freebsd.org/pipermail/freebsd-x11/2012-February/011485.html

mousaka

Ja, das habe ich auch so gemacht, bin dann trotzdem da gelandet wo ich jetzt bin.

edit: ich habe das nochmal sauber ausgecheckt. Der Patch geht jetzt auch sauber durch, die Build-Fehler bleiben aber dieselben.
 
Zuletzt bearbeitet:
Ich habe jetzt nochmal als mit svn RELENG_9 ausgecheckt, weil ich da besser Änderungen revertieren und überprüfen kann. Habe nochmal den Patch applied (mit sed ... und -p3...), und bekomme jetzt ein anderes reject, (Änderungen in der Zwischenzeit?), wieder in Intel. Habe ich angehangen.

Hmpf, also ich weiß, alle machens freiwillig und so, aber wenn man schon einen CFT macht, dann sollten die Tester doch nicht Tage damit verbringen, überhaupt den Code gebaut zu bekommen. Ich zumindest werde mich jetzt erstmal nicht mehr damit beschäftigen.
 

Anhänge

  • i915_suspend.c.rej.txt
    3,4 KB · Aufrufe: 213
Zuletzt bearbeitet:
Zurück
Oben