staging.inyokaproject.org

du mein packetsystem erachtet die rc2 packete als neuer...?!

meinste da is was dran?

gruß rionline

Nö, das ist nicht schlimm. Ich hatte nur Probleme die Versionsnummer richtig hinzubekommen. Ignoriere einfach die Meldung. Der Treiber ist definitiv aktueller als die RC2.

der funzt leider garnicht!

Wahnwitzige Grafikfehler (rand bund...hauptteil schwarz) oder er fährt garnicht nauf.

schade ☹

Wenn die RC2-Version bei dir funktioniert hat, dann solltest du bei dieser bleiben. Ich werde die Treiberentwicklung aber weiterverfolgen, vielleicht wird die Version 2.7.1 besser funktionieren.

ja alles klar....leider wird es dann jetzt doch wieder nix mit uxa dri2....denn der xserver freezt ja in intermetierenden abständen... ☹

meinste ich kann bei xorg, mesa und dri updates hoffen, dass es läuft oder liegt der freeze vermutlich am intel treiber?

frage, weil ich nicht nach jedem besagten packetupdate mir unnötig hoffnungen machen will.

cya & thx

meinste ich kann bei xorg, mesa und dri updates hoffen, dass es läuft oder liegt der freeze vermutlich am intel treiber?

In Jaunty wirst du UXA wahrscheinlich abhaken können. Dazu ist das Thema eine viel zu große Baustelle. Da spielt ja auch noch der Kernel eine wichtige Rolle. So wie ist ausschaut wird UXA wohl erst im Zusammenspiel mit KMS richtig funktionieren. Bei mir läuft UXA komischerweise 100% stabil. Es ist halt definitiv davon anhängig welche Grafikhardware man benutzt.

verstehe....dummerweise schließt das die lauffähigkeit bei mir nicht aus....da ich den 2.6.29.1 installiert habe *g*

na ich werde deine updates auf jeden fall mal probieren! 😉

cya

Hi, also auf meiner X4500M scheint es mit UXA und Deinem Treiber Packet gut zu laufen. Die Frames von GLX Gear sind allerdings trotzdem deutlich geringer. Unter EXA von rund 1300 auf rund 600 bei UXA. Trotzdem läuft der Desktop nicht hakelig oder unrund. Wobei das nach so kurzem Test ich mal lieber abwarte. Eigentlich scheint es mir so als wenn die Effekte besser laufen. Mag aber auch Einbildung sein. Mit Deinem Treiber und EXA hatte ich allerdings gerade auch einen Freeze gehabt. Nichts ging mehr.

Da ich hiermit aber keine Spiele vor habe zu Spielen, sondern lediglich Videowiedergabe wichtig ist, profitiere ich überhaupt vom UXA Modus ?

Cu Torsten

klar du hast glasen gefragt, aber eine brauchbare laienantwort kannste auch von mir haben! 😉

mit UXA wird dein System DRI2 fähig:

somit laufen auch programme wie google earth, stellarium, vlc (opengl ausgabe), und eben alle anderen programme die opengl in irgendeiner weise nutzen nicht mehr via overlay sonderen funktionieren nahtlos auch mit composite-managern wie compiz...

kannste probieren, indem du auf EXA mal das glxgears fenster bissi rumschiebste und dabei mal expose, desktoptafel oder cube laufen lässt!

bye

Torsten73 schrieb:

also auf meiner X4500M scheint es mit UXA und Deinem Treiber Packet gut zu laufen. Die Frames von GLX Gear sind allerdings trotzdem deutlich geringer. Unter EXA von rund 1300 auf rund 600 bei UXA.

glxgears ist ein Maßstab zum Vergleichen. Du musst schon richtige Benchmarks benutzen.

Trotzdem läuft der Desktop nicht hakelig oder unrund. Wobei das nach so kurzem Test ich mal lieber abwarte. Eigentlich scheint es mir so als wenn die Effekte besser laufen. Mag aber auch Einbildung sein.

Mir ist nach dem Umstellen auf UXA vor allem eines aufgefallen :

Der Wechsel der Hintergrundbilder unter GNOME 2.26 läuft deutlich schneller als mit EXA. Mit EXA dauert es mehrere Sekunden bis das Bild ausgetauscht wird, mit UXA geht es in Sekundenbruchteilen.

Mit Deinem Treiber und EXA hatte ich allerdings gerade auch einen Freeze gehabt. Nichts ging mehr.

Wie schon geschrieben, der Treiber ist sehr Hardwareabhängig.

Da ich hiermit aber keine Spiele vor habe zu Spielen, sondern lediglich Videowiedergabe wichtig ist, profitiere ich überhaupt vom UXA Modus ?

Beim Einsatz vom Compiz auf jeden Fall. Und einige 2D-Operationen laufen ja auch deutlich schneller (siehe mein Beispiel).

Auch auf die Gefahr hin, dass es eine dumme Frage ist, ich versuche den 64 bit zu kompilieren (habe mal ubuntu 9.04pre installiert) und scheitere hier:

torsten@AP-VDR:/usr/local/src/xf86-video-intel-2.7.0$ sudo ./autogen.sh
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal 
autoreconf2.50: configure.ac: tracing
autoreconf2.50: running: libtoolize --install --copy
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf2.50: running: /usr/bin/autoconf
autoreconf2.50: running: /usr/bin/autoheader
autoreconf2.50: running: automake --add-missing --copy --no-force
autoreconf2.50: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for bash... /bin/bash
checking if libtool sucks... yup, it does
checking if dolt supports this host... yes, replacing libtool
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for intel-gen4asm... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking for mprotect... yes
./configure: line 12606: syntax error near unexpected token `XINERAMA,'
./configure: line 12606: `XORG_DRIVER_CHECK_EXT(XINERAMA

den patch habe ich vorher im gleichen Verzeichniss einfach so installiert:

torsten@AP-VDR:/usr/local/src/xf86-video-intel-2.7.0$ sudo patch < xf86-video-intel-2.7.0~glasen~ppa1.diff
patching file changelog
patching file compat
patching file control
patching file copyright
patching file 01_gen_pci_ids.diff
patching file 100_change_libdrm.patch
patching file 103_quirk_intel_mb890.patch
patching file 105_no_modesetting.diff
patching file 109_i830-fifo-watermark-conservative.patch
patching file 110_quirk_hp_mini.patch
patching file 112_num_used_fences.patch
patching file series
patching file rules
patching file watch
patching file xserver-xorg-video-intel-dbg.install
patching file xserver-xorg-video-intel.install
patching file xserver-xorg-video-intel.install.hurd-i386
patching file xserver-xorg-video-intel.links
patching file xserver-xorg-video-intel.manpages
patching file xsfbs.mk
patching file xsfbs.sh

Fehlt mir doch noch ein Paket ? Thx

Installiere mal die Pakete "dpkg-dev" und "fakeroot", entpacke den Treiberquellcode nochmal neu, patche ihn und führe folgendes Kommando aus :

dpkg-buildpackage -b -rfakeroot

Sollte noch eine Abhängigkeit fehlen, wird dir diese dann per Fehlermeldung mitgeteilt. Den Kompiliervorgang kannst du als normaler Benutzer durchführen. "sudo" ist nicht notwendig.

P.S. :

Ich weiß jetzt übrigens warum bei rionline der 2.7er Treiber nicht funktioniert. Es liegt an der Kernelversion. Ich habe gestern mal ein wenig mit dem Kernel herumexperimentiert und festgestellt das man, wenn man die Kernelversion 2.6.29 einsetzt, zwingend eine neuere Version der "libdrm" braucht. Meine "gehackte" Version des Treibers funktioniert nur mit der Kernelversion 2.6.28. Benutze ich den 2.6.29er Kernel stürzt der Xserver einfach beim Starten ab.

Gerade habe ich mein erstes PPA eingerichtet. Der Treiber ist online (Auch die 64bit-Version) und kann ab sofort von dort bezogen werden :

https://launchpad.net/~glasen/+archive/ppa

Die Sorge mit der 64bit-Version war völlig unbegründet. Launchpad kompiliert die Pakete nämlich beim Hochladen völlig selbstständig. Dauert ein wenig, dafür muss man sich keinen Kopf über Cross-Compiling machen.

ich habe das Verzeichniss gelöscht und alles neu erstellt, gepatch und nun gibt es dieses:

torsten@AP-VDR:/usr/local/src/xf86-video-intel-2.7.0$ dpkg-buildpackage -b -rfakeroot
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert: 
dpkg-buildpackage: setze LDFLAGS auf Standardwert: -Wl,-Bsymbolic-functions
dpkg-buildpackage: setze FFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CXXFLAGS auf Standardwert: -g -O2
tail: „debian/changelog“ kann nicht zum Lesen geöffnet werden: No such file or directory
dpkg-buildpackage: Fehlschlag: Ende von debian/changelog gab Fehler-Exitstatus 1

Oh ich sehe gerade, dass Dein ppa Online ist. Vielen Dank!!!

Kein Problem. Ich hoffe mal der Treiber bringt euch was.