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 helps. Regards, Felix 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 <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
