I'm looking at the details in the bugzilla entry right now. This may or
may not apply to michalwd1979's problem.
I think the problem happens when r128CreateScreen calls
driParseOptionInfo. It gets the two arguments __driConfigOptions and
__driNConfigOptions. Both are defined in the same r128screen.c file.
The error message indicates that there is a mismatch between the two
variables. I noticed that __driConfigOptions is public, since driconf
needs to be able to access it, while __driNConfigOptions is static.
Both drivers (shared objects) have a __driConfigOptions symbol with the
same name. I guess what's happening is that the dynamic linker resolves
__driConfigOptions to the same object in both drivers in a dual-screen
system. On the second screen that happens to be the wrong one.
I'm not sure how to fix this. Some linker magic may be needed. You need
to make sure that in the r128 driver, __driConfigOptions is resolved to
its own version of the symbol in all cases, even when another driver is
linked in that has a symbol with the same name. I hope this analysis
Am Freitag, den 30.11.2007, 11:06 +0100 schrieb Michel Dänzer:
> On Fri, 2007-11-30 at 08:28 +0100, michalwd1979 wrote:
> > Hello,
> > I found this report [Bug 10132] New: dri doesn't work on second head
> > (r128) on the archives, and it seems to be also my problem (radeon
> > 7000 and mga card). I would risk a statement that it would hit any
> > system with 2 drivers that use different options. It is quite strange
> > that there is so little reports about this.
> I guess that kind of setup is rare.
> > I have tried to find out where the problem is, but I am not a dri
> > developer and it was ... hard. I simply have no idea why both drivers
> > get option list form first screen. Do You think that I have any chance
> > to find the problem? I can spend some time working on it but please
> > point me to right direction. Where should I start looking?
> I'd start by tracing driParseConfigFiles() to make sure it really only
> parses options for the specified screen/driver.
> I'm Cc'ing Felix Kühling, who wrote the driconf code and might be able
> to give more hints.
> For your reference Felix, the bug report mentioned above is
> https://bugs.freedesktop.org/show_bug.cgi?id=10132 .
> > I am not sure if I am right but it seems that drivers get theirs
> > options from xorg.conf and then form drirc file. I tried to play with
> > options in drirc, but this not change anything. In my case MGA drivers
> > constantly gets options defined in xorg.conf for radeon and fails. But
> > how this options were send to it? drirc files are readed when opengl
> > application starts and opens drivers but what is going on with the
> > list from xorg.conf?
> xorg.conf options don't (directly) affect the Mesa drivers, so they're
> probably irrelevant for this.
| Felix Kühling <fxkuehl@...> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |