Am 20.07.2012 17:10, schrieb Adam Jackson:
autoconf bug! Nice find.
I think the test for "-fPIC" support is fundamentally
broken and should be fixed. Or would it be better
to check for -v and --verbose in CFLAGS?
It sounds like the test is broken, yeah. Although I wonder how many other
st
On 7/20/12 8:03 AM, Knut Petersen wrote:
Am 18.07.2012 16:29, schrieb Adam Jackson:
So this really honestly is a toolchain problem, not a driver problem.
Neither icecream nor gcc are broken.
The solution is pretty simple:
Never ever include -v or --verbos
Am 18.07.2012 16:29, schrieb Adam Jackson:
So this really honestly is a toolchain problem, not a driver problem.
Neither icecream nor gcc are broken.
The solution is pretty simple:
Never ever include -v or --verbose in CFLAGS
==
On 7/18/12 6:34 PM, Chris Wilson wrote:
On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson wrote:
It's not clear to me if, subsequent to your change, DRI would work with
NoAccel.
It does. The mapping of the ring and control registers was already
managed outside of the XAA specific routines, so
Am 18.07.2012 21:34, schrieb Adam Jackson:
So, one difference between the driver you built and the driver in
factory:
http://download.opensuse.org/pub/opensuse/factory/repo/oss/suse/i586/xf86-video-intel-2.20.0-1.1.i586.rpm
Is that yours has this, and theirs doesn't:
hate:~% eu-readelf -a inte
On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson wrote:
> So we default to asking for XAA, and if it doesn't load (because you
> built without it) then neither will the driver; conversely, if XAA
> loads, DRI's use of XAA symbols would be safe. You'd have to have asked
> for Option "NoAccel" to h
On Wed, 2012-07-18 at 15:36 +0100, Chris Wilson wrote:
> On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson wrote:
> > So those should resolve lazily, which means if you never call them they
> > never _need_ to resolve. And this is how X drivers normally work,
> > notice that libfb isn't loaded _be
On Wed, 2012-07-18 at 20:04 +0200, Knut Petersen wrote:
> Ok, I built caef63e0268e59e439b030a9a338e81d5cf8e311 using
>
> export MYROOT=/home/knut/git/X11-t
> export PREFIX=$MYROOT/usr
> export EPREFIX=$PREFIX
> export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig
> export PATH=$PR
Ok, pushed yet another patch to reimplement those tables within i810. I
couldn't spot any more obvious XAA functions called from i810_accel, so
hopefully this will be the last iteration!
Sigh. Wish you hadn't, the linker behaviour he's seeing is _broken_.
Just because we don't know why doesn't
On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson wrote:
> So those should resolve lazily, which means if you never call them they
> never _need_ to resolve. And this is how X drivers normally work,
> notice that libfb isn't loaded _before_ you load your driver but yet the
> driver loads.
They we
On Wed, 2012-07-18 at 15:07 +0100, Chris Wilson wrote:
> On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson wrote:
> > On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
> > > On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen
> > > wrote:
> > > > Some XAA code still waits for a sudden death:
>
On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson wrote:
> On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
> > On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen
> > wrote:
> > > Some XAA code still waits for a sudden death:
> > >
> > > [ 35756.654] (EE) Failed to load
> > > /home/knut/gi
On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
> On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen
> wrote:
> > Some XAA code still waits for a sudden death:
> >
> > [ 35756.654] (EE) Failed to load
> > /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
> > /home/knut/git/
A second attempt is now online. If I got my grepping correct, only the
xaa specific routines are in i810_xaa.c and not built with
--disable-xaa.
Some XAA code still waits for a sudden death:
[ 35756.654] (EE) Failed to load
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
/hom
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
undefined symbol: XAAGetPatternROP
That's... surprising. That should only be fatal if you have LD_BIND_NOW
semantics turned on, which is not the default. What OS are you running? Any
special security or compiler options?
- a
On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen
wrote:
> Am 17.07.2012 22:41, schrieb Chris Wilson:
> > On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
> > wrote:
> >> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
> >> wrote:
> >>> Current Xorg tree builds without problems but fails to
On 7/17/12 4:54 PM, Knut Petersen wrote:
Am 17.07.2012 22:41, schrieb Chris Wilson:
On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
wrote:
On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
wrote:
Current Xorg tree builds without problems but fails to
load intel_drv.so. Xorg log and build sc
Am 17.07.2012 22:41, schrieb Chris Wilson:
On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
wrote:
On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
wrote:
Current Xorg tree builds without problems but fails to
load intel_drv.so. Xorg log and build script attached.
Ok, looks like the xaa r
Ok, looks like the xaa removal from i810 was snafu. Let me split out the
common ring functions from the xaa acceleration routines...
In the meantime compile with --enable-kms-only.
-Chris
Well, after compiling with --enable-kms-only the module is still broken.
But there are always some old x
On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
wrote:
> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
> wrote:
> > Current Xorg tree builds without problems but fails to
> > load intel_drv.so. Xorg log and build script attached.
>
> Ok, looks like the xaa removal from i810 was snafu. Let
On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
wrote:
> Current Xorg tree builds without problems but fails to
> load intel_drv.so. Xorg log and build script attached.
Ok, looks like the xaa removal from i810 was snafu. Let me split out the
common ring functions from the xaa acceleration rout
21 matches
Mail list logo
