Testing latest -intel in Ubuntu

[tormod]

I saw on the archive page that KMS was disabled in 20090127 because it wouldn't build. Is this structural or only this version? In other words: Do I need to build myself if I want to test kms against 2.6.29-rc3 or could it be enabled in next attempt if it builds?

It is not the fault of the -intel version but the lack of necessary headers and support in the 2.6.28 kernel. So unless kernel kms stuff is backported from 2.6.29 into the Jaunty kernel, the -intel kms will not build in Jaunty.

If you install 2.6.29 yourself, you can download the xorg-edgers -intel source package, and change configure.ac to build kms.

[mrvanes]

It is not the fault of the -intel version but the lack of necessary headers and support in the 2.6.28 kernel. So unless kernel kms stuff is backported from 2.6.29 into the Jaunty kernel, the -intel kms will not build in Jaunty.

If you install 2.6.29 yourself, you can download the xorg-edgers -intel source package, and change configure.ac to build kms.

Is a kms enabled intel driver compatible with 2.6.28 old-setting method? Could I use this kms enabled driver to both test kms in 2.6.29 and boot into 2.6.28 without kms?

[tormod]

Is a kms enabled intel driver compatible with 2.6.28 old-setting method? Could I use this kms enabled driver to both test kms in 2.6.29 and boot into 2.6.28 without kms?

Good question Unfortunately I don't have Intel hardware so I can not test these things myself. I would guess you can get an answer on #intel-gfx unless someone else jumps in here. It should be possible to have a both-ways compatible intel driver that probes the drm for kms and does its own mode setting if needed, but I don't know if they develop it this way.

OTOH, the way the kernel and intel driver are getting intertwined, I am not even sure a driver built on 2.6.29 will run on 2.6.28, for other reasons than kms.

[Peter_Cordes]

problems building mesa with auto-xorg-git

I've been fooling around with auto-xorg-git for a while, and reading some about git itself, since auto-xorg-git does some tricky stuff with the debian repos and the fd.o repos.

I changed auto-xorg-git to build a binary package, instead of a signed source package, since that's what I want. Should I be doing something different, like building a source package and then making binaries from it? (and if so, why?)

The problem is that debuild -us -uc -i -b fails with linking problems, maybe because not all the objects were compiled with -fPIC.

./auto-xorg-git -g -H hooks -p mesa  -b mesa_7_4_branch

gcc -c -I../../../../include -I../../../../src/mesa -I../../../../src/mesa/main -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 -ff
ast-math -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM xm_tri.c -o xm_tri.o
mklib: Making Linux shared library:  libGL.so.1.5.070300
/usr/bin/ld: ../../../../src/mesa/libglapi.a(glapi_x86-64.o): relocation R_X86_64_PC32 against symbol `_gl_DispatchTSD' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
mklib: Installing libGL.so.1.5.070300 libGL.so.1 libGL.so in ../../../../lib
mv: cannot stat `libGL.so.1.5.070300': No such file or directory
make[5]: *** [../../../../lib/libGL.so] Error 1
make[5]: Leaving directory `/usr/local/src/g965/xorg-pkg-tools/mesa/obj-x86_64-linux-gnu/swx11+glu/src/mesa/drivers/x11'
make[4]: *** [default] Error 1
make[4]: Leaving directory `/usr/local/src/g965/xorg-pkg-tools/mesa/obj-x86_64-linux-gnu/swx11+glu/src/mesa/drivers'
make[3]: *** [driver_subdirs] Error 2
make[3]: Leaving directory `/usr/local/src/g965/xorg-pkg-tools/mesa/obj-x86_64-linux-gnu/swx11+glu/src/mesa'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/usr/local/src/g965/xorg-pkg-tools/mesa/obj-x86_64-linux-gnu/swx11+glu/src'
make[1]: *** [default] Error 1
make[1]: Leaving directory `/usr/local/src/g965/xorg-pkg-tools/mesa/obj-x86_64-linux-gnu/swx11+glu'
make: *** [debian/stamp/x86_64-linux-gnu-build-swx11+glu] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
debuild: fatal error at line 1329:
dpkg-buildpackage -rfakeroot -D -us -uc -i -b failed

I didn't do any custom config of mesa, and I don't think I screwed up my source tree with git... I ran into this exact build error a few days ago, but I didn't report it because I was less sure of what was going on with git and my kernel headers. (now I have linux-headers-2.6.28-7-generic installed, from a package I built from Ubuntu's git kernel sources, because the jaunty package requires a libc newer than Intrepids. . Fortunately, http://blog.avirtualhome.com/2008/10...pid-using-git/ was helpful, along with https://help.ubuntu.com/community/Kernel/Compile.)

In my mesa git, I did

git branch -D upstream-head
...
git fetch freedesktop refs/heads/mesa_7_4_branch:refs/heads/upstream-head

so auto-xorg-git would get the stable branch of mesa, instead of the master branch that get_unstable() in auto-xorg-git normally sets up the repo to track.

[tormod]

I've been fooling around with auto-xorg-git for a while, and reading some about git itself, since auto-xorg-git does some tricky stuff with the debian repos and the fd.o repos.

Cool!

I changed auto-xorg-git to build a binary package, instead of a signed source package, since that's what I want. Should I be doing something different, like building a source package and then making binaries from it? (and if so, why?)

No, that's fine, you can build binaries directly. I originally had it build both sources and binaries, but now most of the time I only build sources and upload them to a PPA without building binaries locally, since I don't have a fast computer.

The problem is that debuild -us -uc -i -b fails with linking problems, maybe because not all the objects were compiled with -fPIC.

Sounds familiar. If you look at the changelog for the xorg-edgers mesa packages, you can see that I merged with origin/ubuntu instead of debian-experimental, because the Ubuntu branch had some fixes for this. Just add "-d origin/ubuntu" to the auto-xorg-git line.

In my mesa git, I did

git branch -D upstream-head
...
git fetch freedesktop refs/heads/mesa_7_4_branch:refs/heads/upstream-head

so auto-xorg-git would get the stable branch of mesa, instead of the master branch that get_unstable() in auto-xorg-git normally sets up the repo to track.

This is not necessary: If you use "auto-xorg-git -b mesa_7_4_branch" it will use the stable 7.4 branch. If you don't specify -b, it will use master. Note the function in the script is "get-upstream" (not get-unstable) and it fetches from $BRANCH which is taken from -b.

Good luck further!

[marijus]

hi tormod,

i have a problem with intel driver 2.6.99...

(WW) intel(0): Unable to find initial modes
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.

im using intel 855GM on up to date jaunty
no problems with 2.6.0 or 2.6.1 drivers.
any help appreciated...
regards, marijus

[kxmas]

Tormod, I'm pleased to let you know that I've been running 2:2.6.99.1+git20090207.3aa8591a-0ubuntu0tormod2 with UXA all day with zero X11 freezes.

KDE 4.2 with compositing is a pleasure to use.

[kxmas]

Tormod, I'm pleased to let you know that I've been running 2:2.6.99.1+git20090207.3aa8591a-0ubuntu0tormod2 with UXA all day with zero X11 freezes.

KDE 4.2 with compositing is a pleasure to use.

Correction: No freezes until I enabled the second display at work.

[tormod]

hi tormod,

i have a problem with intel driver 2.6.99...

(WW) intel(0): Unable to find initial modes
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.

im using intel 855GM on up to date jaunty
no problems with 2.6.0 or 2.6.1 drivers.
any help appreciated...
regards, marijus

Marijus, this sounds like a regression but it is hard to see what is wrong without seeing the full log. I suggest you file a bug report at https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

See also http://intellinuxgraphics.org/how_to_report_bug.html

[stetzen]

That's looks strange, but I'm getting better 3d performance with EXA than with UXA at the moment!

EXA: ~650 fps at glxgears, ~15 fps at Extreme Tux Racer
UXA: ~400 fps at glxgears, ~10 fps at Extreme Tux Racer

VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

xserver-xorg-video-intel 2:2.6.1-1ubuntu2

Another large problem of UXA is a huge memory leak with compiz. compiz.real process starts to use up to 500 mb of RAM ang 1500 mb of swap at some point. It seems to be not only my problem, according to what I've read at ubuntuforums.