Re: [Dri-devel] dri cvs needs newest expat?
On Tue, 14 Oct 2003 04:25:23 +0200
Roland Scheidegger [EMAIL PROTECTED] wrote:
cvs trunk will no longer compile for me:
gcc ... xmlconfig.c
xmlconfig.c:268:29: warning: ISO C does not permit named variadic macros
xmlconfig.c:280:27: warning: ISO C does not permit named variadic macros
xmlconfig.c:294:27: warning: ISO C does not permit named variadic macros
xmlconfig.c: In function `driParseOptionInfo':
xmlconfig.c:499: warning: ISO C forbids forward references to `enum' types
xmlconfig.c:499: storage size of `s' isn't known
xmlconfig.c:531: `XML_STATUS_OK' undeclared (first use in this function)
xmlconfig.c:531: (Each undeclared identifier is reported only once
xmlconfig.c:531: for each function it appears in.)
xmlconfig.c:499: warning: unused variable `s'
xmlconfig.c: In function `parseOneConfigFile':
xmlconfig.c:711: warning: ISO C forbids forward references to `enum' types
xmlconfig.c:711: storage size of `s' isn't known
xmlconfig.c:734: `XML_STATUS_OK' undeclared (first use in this function)
xmlconfig.c:711: warning: unused variable `s'
make: *** [xmlconfig.o] Fehler 1
Some quick googling shows this looks like it's some compatibility
problem with expat. Currently, I have installed expat 1.95.4 (SuSE 8.1,
gcc 3.2).
Am I just supposed to upgrade expat? That's no problem, but aren't all
those expat 1.95.x releases supposed to be source (and binary) compatible?
José reported a similar problem with building the snapshots but solved
it, probably by upgrading expat. Also Alan upgraded the expat version in
XFree86 CVS, so there wont be a problem when the config stuff goes into
XFree86.
Anyway, does the attached patch work for you. It compiles ok with expat
1.95.6 here.
Roland
Regards,
Felix
__\|/_____ ___ -
Felix ___\_e -_/___/ __\___/ __\_ You can do anything,
Kühling (_\Ä// /_/ /) just not everything
[EMAIL PROTECTED] \___/ \___/ Uat the same time.
Index: xmlconfig.c
===
RCS file: /cvs/dri/xc/xc/lib/GL/mesa/src/drv/common/xmlconfig.c,v
retrieving revision 1.2
diff -u -r1.2 xmlconfig.c
--- xmlconfig.c 9 Oct 2003 09:55:58 - 1.2
+++ xmlconfig.c 14 Oct 2003 13:00:17 -
@@ -496,7 +496,7 @@
void driParseOptionInfo (driOptionCache *info) {
XML_Parser p;
-enum XML_Status s;
+int status;
struct OptInfoData userData;
struct OptInfoData *data = userData;
GLuint nOptions;
@@ -527,8 +527,8 @@
userData.inEnum = GL_FALSE;
userData.curOption = -1;
-s = XML_Parse (p, __driConfigOptions, strlen (__driConfigOptions), 1);
-if (s != XML_STATUS_OK)
+status = XML_Parse (p, __driConfigOptions, strlen (__driConfigOptions), 1);
+if (!status)
XML_FATAL (%s., XML_ErrorString(XML_GetErrorCode(p)));
XML_ParserFree (p);
@@ -708,7 +708,7 @@
static void parseOneConfigFile (XML_Parser p) {
#define BUF_SIZE 0x1000
struct OptConfData *data = (struct OptConfData *)XML_GetUserData (p);
-enum XML_Status s;
+int status;
int fd;
if ((fd = open (data-name, O_RDONLY)) == -1) {
@@ -730,8 +730,8 @@
data-name, strerror (errno));
break;
}
- s = XML_ParseBuffer (p, bytesRead, bytesRead == 0);
- if (s != XML_STATUS_OK) {
+ status = XML_ParseBuffer (p, bytesRead, bytesRead == 0);
+ if (!status) {
XML_ERROR (%s., XML_ErrorString(XML_GetErrorCode(p)));
break;
}
Re: [Dri-devel] dri cvs needs newest expat?
Felix Kühling wrote: Some quick googling shows this looks like it's some compatibility problem with expat. Currently, I have installed expat 1.95.4 (SuSE 8.1, gcc 3.2). Am I just supposed to upgrade expat? That's no problem, but aren't all those expat 1.95.x releases supposed to be source (and binary) compatible? José reported a similar problem with building the snapshots but solved it, probably by upgrading expat. Also Alan upgraded the expat version in XFree86 CVS, so there wont be a problem when the config stuff goes into XFree86. Anyway, does the attached patch work for you. It compiles ok with expat 1.95.6 here. Still some ISO C warnings, but it compiles just fine with that patch (and expat 1.95.4) now. Though if expat is in the xfree86 tree (didn't know that) this makes that problem a non-issue I guess. Now I can go on to the testing of that config stuff ;-) Roland --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
On Mon, 2003-10-13 at 18:14, Alex Deucher wrote: it seems to crash while validaing the modes on the second head. I don't know why it should work on linux but not freebsd. Maybe your code makes assumptions which are true on Linux but false on FreeBSD, e.g. something related to memory allocation? Of course, a backtrace would be better than guessing what it could be. :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 791] radeon_vtxfmt_x86.c does not compile
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=791 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-14-10 13:19 --- Assigning to the DRI. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texture problem with i810
Dave Airlie wrote: I've noticed an issue with the i810 chipset that I'm wondering if anyone can shed light on it.. I've it narrowed down to the fact that the texture upload code never gets called for my texture, so the card doesn't know what to display, hence it displays white space. To repeat - get an i81x (may be an issue on i830 also.. ) get texture demo from Mesa-5.0 take wrs_logo.rgb from Mesa-5.0 and use xv to make it 1024x864 and save it, convert to a pnm, run texture with the image file... Now if you've got your VideoRAM setting set to 16384 you get white space, if you set the VideoRAM setting to 18000 the image displays... So I know 16384 is plenty of VideoRAM so why the whitespace? What's the maximum texture size reported by 'glxinfo -l'? My guess is that it's less than 1024*1024. If that's the case, when glTexImage is called, it probably returns an error, and you get a white texture. :) --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
what's the difference between the two? why does linux have it's own version? why couldn't the linux version be used with BSD? something to do with the kernel? Alex --- Eric Anholt [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 09:14, Alex Deucher wrote: If the mode validation interacts with the bios at all (I don't really know this stuff), one major difference between Linux and FreeBSD is use of emulation for int10. On a Linux system, you can use emulation like on FreeBSD by moving /usr/X11R6/lib/modules/linux/libint10.a out of the way so the generic (emulation) one is used. Int10 and the emulation for it is the most common cause of differences between Linux and *BSD for 2d in XFree86, I would say. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
Martin Spott wrote: Alex Deucher [EMAIL PROTECTED] wrote: I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. I'm fine with running the 'new' X server _modules_ with a previously built XFree86 binary when I install the new stuff without restarting the X server I'm currently using. Unfortunately the 'new' X server core binary fails to run at my default resolution [EMAIL PROTECTED] Hz but falls back to 1024x768 at somewhat around 60 Hz (usual effects of too low refresh rate). 'xdpyinfo' fails to print the _real_ parameters: I have a similar problem. Though in my case, I don't get a picture at all - the monitor just goes to standby. Disabling MergedFB solves the problem. Config file can be found here: http://homepage.hispeed.ch/rscheidegger/XF86Config.mergedfb log file: http://homepage.hispeed.ch/rscheidegger/XFree86.0.log something with the mode validation seems fishy... And I also get some minor corruption if I run games fullcreen (with MergedFB disabled), when the fullscreen resolution of the game is the same as the virtual resolution - nwn showed a blue line at the right and the bottom edge, Quake III showed a similar problem. But at least the snow is now gone thanks to Hui's patch. That means I can finally upgrade XFree86 my 2nd PC with a radeon 7200sdr - the snow was unbearable with XFree86 4.3 on that machine. Roland --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
--- Roland Scheidegger [EMAIL PROTECTED] wrote: Martin Spott wrote: Alex Deucher [EMAIL PROTECTED] wrote: I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. I'm fine with running the 'new' X server _modules_ with a previously built XFree86 binary when I install the new stuff without restarting the X server I'm currently using. Unfortunately the 'new' X server core binary fails to run at my default resolution [EMAIL PROTECTED] Hz but falls back to 1024x768 at somewhat around 60 Hz (usual effects of too low refresh rate). 'xdpyinfo' fails to print the _real_ parameters: I have a similar problem. Though in my case, I don't get a picture at all - the monitor just goes to standby. Disabling MergedFB solves the problem. Config file can be found here: http://homepage.hispeed.ch/rscheidegger/XF86Config.mergedfb log file: http://homepage.hispeed.ch/rscheidegger/XFree86.0.log something with the mode validation seems fishy... Part of the problem is I'm not entirely sure how the hardware/driver decides what output gets assigned to what crtc. In windows you can change this, in xfree86, it's done sort of automatically. The driver assumes that the DVI/LCD port is the primary and the crt port is the secondary. however if there's nothing attached to the DVI port, the vga port should be attached to crtc1, but that doesn't always happen. it looks like, in your case, that it's reversing the outputs (the 1280x1024 mode is being sent to the other port and the 0x0 is being sent to your monitor). to make matter worse some OEMs reverse how the DACs are wired or which pins the DDC info come in on for each head. All of which makes figuring out the modes kind of a PITA. I plan to delve into this more next time I get a chance. Take a look at the various mode validation functions in the radeon driver! it's enough to make your head spin! The reason mergedfb is enabled by default is to emulate the clone behavior in the old driver. perhaps this should be changed in the future? In the mean time, I may switch back to validating the modes on crtc2 before crtc1. that was the way I had it initially and the way it was for clone mode. I switched it when I was working on a sort of autoconfigure for mergedfb. however, that didn't work out as expected due to the way the radeon ddc functions are structured. they need to be reworked to make autoconfig work properly. Although I don't know why the order should matter, but you never know... UGH... I HATE dealing with modes... And I also get some minor corruption if I run games fullcreen (with MergedFB disabled), when the fullscreen resolution of the game is the same as the virtual resolution - nwn showed a blue line at the right and the bottom edge, Quake III showed a similar problem. Hmmm... I haven't seen any problems with OpenGL here (in mergedfb and non-mergedfb modes), other than the corruption I'm seeing with a 3d window that's 2048 pixels wide . But at least the snow is now gone thanks to Hui's patch. That means I can finally upgrade XFree86 my 2nd PC with a radeon 7200sdr - the snow was unbearable with XFree86 4.3 on that machine. Roland __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
On Tue, 2003-10-14 at 10:38, Alex Deucher wrote: what's the difference between the two? why does linux have it's own version? why couldn't the linux version be used with BSD? something to do with the kernel? Yes. The linux-specific module uses the vm86 support of linux to do the int10 execution. The BSDs offer something similar to linux, I think, but at least there isn't a module for it, so we use the generic emulation. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Adding hardware detection to DRI drivers
Standalone Mesa doesn't have the Xfree code for walking the PCI bus so the simplest way for me to find the hardware is to make the DRI drivers aware of the OS's PCI probing support. I've already have PCI probing support added to all of the DRI drivers, but I need to come up with an API that won't break existing Xfree binaries. My first attempt was to make DRM_IOCTL_GET_UNIQUE be already filled out with the hardware name. But this doesn't work since apps check to see if UNIQUE is null before assigning a device. I would have though that they would also check to see if it was equal to the device they were looking for. Would it be better to add a new IOCTL like GET_SUGGESTED_UNIQUE? This would allow Xfree to continue as is, and standalone Mesa would get the suggested ID and then store it back with SET_UNIQUE. I was hoping to do this without adding another IOCTL but I can't seem to come up with a scheme that works. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Multiple VTs with DRI
If I am running two copies of Xfree/DRI on different VT's and both are using the same hardware, is 3D state maintained on VT switch? Including all of the texture memory? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Multiple VTs with DRI
As I recall, no. As it is now, only a single instance of Xfree86 can use the DRI. I think it might be possible by adapting the resume code to reinitialize state and agp on a VT switch, however, I may be wrong. Alex --- Jon Smirl [EMAIL PROTECTED] wrote: If I am running two copies of Xfree/DRI on different VT's and both are using the same hardware, is 3D state maintained on VT switch? Including all of the texture memory? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Multiple VTs with DRI
--- Alex Deucher [EMAIL PROTECTED] wrote: As I recall, no. As it is now, only a single instance of Xfree86 can use the DRI. I think it might be possible by adapting the resume code to reinitialize state and agp on a VT switch, however, I may be wrong. Alex Am I right in thinking that suspend/resume and VT switch should be the same piece of code with slightly different behavior? Does the suspend/resume code save all of the texture memory and AGP state? Or does it rebuild it? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [XFree86] ATI Mach64 direct rendering
Risenhoover, Paul wrote: I've been trying to get DRI working on an ATI Mach64. It's running RedHat 8.0 and I just used up2date to ensure I got all new code, plus the new kernel. I've attached all the obligatory files for your review. There's no official 3D driver for that card. There is an in-progress driver at http://dri.sf.net/. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
