Re: [Dri-devel] Major mergedFB rework committed to CVS
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: name of display:quickstep.plesnik.bonsai.de:0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:40399012 XFree86 version: 4.3.99.12 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: [...] default screen number:0 number of screens:1 screen #0: dimensions:1152x864 pixels (361x271 millimeters) This is _definitely wrong !!! resolution:81x81 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 root window id:0x48 depth of root window:16 planes [...] The effect appears with 24 bpp as well. There is _not_ virtual resolution defined and I did not change my XF86Config since september, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] weird corruption with r200
On Mon, 2003-10-13 at 06:13, Alex Deucher wrote: You can have as big a virtual desktop as you want so long as the total 3D contexts are not greater than 2048 in either direction. Wrong. The 2048 limit is for the virtual location of the right and bottom edges of 3D windows. The 3D engine couldn't care less about what the CRTCs do with the data it renders, except for the bandwidth. -- 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
Re: [Dri-devel] Video Memory Corruption
On Mon, 2003-10-13 at 18:52, Chris Ison wrote: can someome please tell me whats causing the video corruption in the attached png image, and explain how to fix it. Does setting the RADEON_GARTTEXTURING_FORCE_DISABLE environment variable work around it? -- 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
Re: [Dri-devel] Video Memory Corruption
On Mon, 2003-10-13 at 12:15, Michel Dnzer wrote: On Mon, 2003-10-13 at 18:52, Chris Ison wrote: can someome please tell me whats causing the video corruption in the attached png image, and explain how to fix it. Does setting the RADEON_GARTTEXTURING_FORCE_DISABLE environment variable work around it? Whoops, you're using the r200 driver, so forget about that. Please provide some information as in X server log snippets, any interesting 3D client or kernel output, ... -- 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] Environment variables override config file? (was: [Announce] config-0-0-1-branch merged to the trunk)
On Sun, 12 Oct 2003 22:46:38 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2003-10-12 at 00:15, Felix Kühling wrote: On Sat, 11 Oct 2003 01:49:27 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: This means that most environment variables stop working [...] How hard do you think it would be to allow options to be overridden by environment variables for debugging, along the lines of tcl_mode=0 torcs It would be quite simple. But I think we should not allow this in production builds (e.g. snapshots ;-). Why not? What if the warnings were always printed? IIRC not allowing environment variables to change the configuration was supposed to avoid unreproducible bugs. Always printing warnings to stderr may be a good compromise though. If you really need environment variables feel free to commit my patch (with that modification). IMHO changing an option in driconf is as fast as or faster than typing an environment variable. Especially enum options are much more comfortable as you don't have to look up the meaning somewhere else. The attached patch should do the trick. Indeed, thanks. Thanks for the new driconf release. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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 787] Driver is throwing bad mode in r200SetCliprects
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=787 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-13-10 06:59 --- 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
[Dri-devel] [Bug 788] DRI lockup on Radeon 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=788 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-13-10 07:01 --- 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
[Dri-devel] [Bug 672] XFree86 hangs when DRI enabled on a Radeon 7500 PCI
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=672 --- Additional Comments From [EMAIL PROTECTED] 2003-13-10 07:07 --- Can you try again with current CVS, or with Option ForcePCIMode? (It looks like it's trying to initialize AGP for the card...) -- 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] Re: Environment variables override config file?
On Mon, 2003-10-13 at 12:50, Felix Khling wrote: On Sun, 12 Oct 2003 22:46:38 +0200 Michel Dnzer [EMAIL PROTECTED] wrote: On Sun, 2003-10-12 at 00:15, Felix Khling wrote: On Sat, 11 Oct 2003 01:49:27 +0200 Michel Dnzer [EMAIL PROTECTED] wrote: This means that most environment variables stop working [...] How hard do you think it would be to allow options to be overridden by environment variables for debugging, along the lines of tcl_mode=0 torcs It would be quite simple. But I think we should not allow this in production builds (e.g. snapshots ;-). Why not? What if the warnings were always printed? IIRC not allowing environment variables to change the configuration was supposed to avoid unreproducible bugs. Always printing warnings to stderr may be a good compromise though. IMHO it is, but I'm very interested in other opinions. IMHO changing an option in driconf is as fast as or faster than typing an environment variable. When trying different values for a setting, without environment variables I have to * switch to the driconf window (or the editor with ~/.drirc open) * change the setting * save the settings * switch back to the terminal * start the app whereas with environment variables, I only have to * go back in the shell history * change the setting * press enter and I don't have to remember what the settings were before. Especially enum options are much more comfortable as you don't have to look up the meaning somewhere else. That only matters the first couple of times you play with a setting. :) -- 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
Re: [Dri-devel] Video Memory Corruption
Chris Ison [EMAIL PROTECTED] wrote: --Boundary_(ID_KcARw6HFWym7RIWbxkMyIg) Content-type: text/plain Content-transfer-encoding: 7BIT can someome please tell me whats causing the video corruption in the attached png image, and explain how to fix it. I'd say the main bug is _YOU_ posting a 3/4 MByte image to a mailing list ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher 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. Alex __ 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 --- 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] Video Memory Corruption
On Mon, 2003-10-13 at 13:46, Martin Spott wrote: Chris Ison [EMAIL PROTECTED] wrote: can someome please tell me whats causing the video corruption in the attached png image, and explain how to fix it. I'd say the main bug is _YOU_ posting a 3/4 MByte image to a mailing list ! Well, it's only half a meg here ;), but it would certainly have been better to put it up on some webspace. I didn't realize in the list admin interface it was this big, or I wouldn't have approved the post, sorry about that. -- 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
Re: [Dri-devel] Re: Environment variables override config file?
Michel Dnzer wrote: On Mon, 2003-10-13 at 12:50, Felix Khling wrote: On Sun, 12 Oct 2003 22:46:38 +0200 Michel Dnzer [EMAIL PROTECTED] wrote: On Sun, 2003-10-12 at 00:15, Felix Khling wrote: On Sat, 11 Oct 2003 01:49:27 +0200 Michel Dnzer [EMAIL PROTECTED] wrote: This means that most environment variables stop working [...] How hard do you think it would be to allow options to be overridden by environment variables for debugging, along the lines of tcl_mode=0 torcs It would be quite simple. But I think we should not allow this in production builds (e.g. snapshots ;-). Why not? What if the warnings were always printed? IIRC not allowing environment variables to change the configuration was supposed to avoid unreproducible bugs. Always printing warnings to stderr may be a good compromise though. IMHO it is, but I'm very interested in other opinions. IMHO changing an option in driconf is as fast as or faster than typing an environment variable. When trying different values for a setting, without environment variables I have to * switch to the driconf window (or the editor with ~/.drirc open) * change the setting * save the settings * switch back to the terminal * start the app This would be a real pain during development... whereas with environment variables, I only have to * go back in the shell history * change the setting * press enter and I don't have to remember what the settings were before. I would definitely find this less painful... Keith --- 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
Alright... You can ignore the unresolved symbol messages. That was my mistake. However, the X server is still crashing under FreeBSD with the MergedFB option enabled. Adam On Mon, 13 Oct 2003, Adam K Kirchhoff wrote: Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher 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. Alex __ 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 --- 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
hmmm... Have you ever gotten mergedfb working under freebsd? I've never tested on freebsd. can you send your log? Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Alright... You can ignore the unresolved symbol messages. That was my mistake. However, the X server is still crashing under FreeBSD with the MergedFB option enabled. Adam On Mon, 13 Oct 2003, Adam K Kirchhoff wrote: Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher 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. Alex __ 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
Can you clarify what you tried and what the problem is? Does everything work as expected when using a particular XFree86 binary and not with another, or are you having a problem with the changes I committed last night? If you are having trouble with the driver, there are a couple of things you can try: Option MergedFB false Mergedfb is on by default as it provides a clone mode. this is to match the behavior of the old radeon driver clone mode. setting it to false disables the 2nd crtc. crtc1 then drives both displays. Try defining a virtual resolution of 1152x864 and seen if that fixes it. Send a copy of your log file. Alex --- Martin Spott [EMAIL PROTECTED] 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: name of display:quickstep.plesnik.bonsai.de:0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:40399012 XFree86 version: 4.3.99.12 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: [...] default screen number:0 number of screens:1 screen #0: dimensions:1152x864 pixels (361x271 millimeters) This is _definitely wrong !!! resolution:81x81 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 root window id:0x48 depth of root window:16 planes [...] The effect appears with 24 bpp as well. There is _not_ virtual resolution defined and I did not change my XF86Config since september, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! __ 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] weird corruption with r200
You are right. Last night I created a virtual desktop of 2100x768 and display mode of 1024x768, then ran several fullscreen GL xscreensaver hacks. All of them displayed fine. I haven't looked at the source to the hacks, but I assume they look at the current display mode and the create a 3D window of that size, 1024x768 in this case. I guess the GL screensavers may be draw their 3D window at starting at 0,0. The only time I see the rendering fail is when the actual 3D window(s) itself exceeds 2048. For instance if I resize a glxgears window, it will render fine up to 2048, then the window goes blank, or if I run several instances of glxgears lined up, the one that exceeds 2048 will go blank. perhaps the limit is actually 2047? that wouldn't seem to be the case since rendering still happens at 2048 it's just full of arifacts. perhaps it is bandwidth. I downloaded the newest version of xscreensaver last night. the new behavior is to create 2 instances of the GL hack based on the xinerama info and display one on head head. the hack running on the first head displays fine; the one running on the second head shows the corruption. So it seems to have something to do with 2048. Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 06:13, Alex Deucher wrote: You can have as big a virtual desktop as you want so long as the total 3D contexts are not greater than 2048 in either direction. Wrong. The 2048 limit is for the virtual location of the right and bottom edges of 3D windows. The 3D engine couldn't care less about what the CRTCs do with the data it renders, except for the bandwidth. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ 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] weird corruption with r200
Also, I don't think it's a bandwith issue. I can run mergedfb in above mode with a virtual desktop of 1280x1792 (1024x768 above 1280x1024) and all is well. this is signifigantly more bandwidth than 2048x768. Unless the pitch has more to do with it than the height... Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 06:13, Alex Deucher wrote: You can have as big a virtual desktop as you want so long as the total 3D contexts are not greater than 2048 in either direction. Wrong. The 2048 limit is for the virtual location of the right and bottom edges of 3D windows. The 3D engine couldn't care less about what the CRTCs do with the data it renders, except for the bandwidth. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ 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] weird corruption with r200
On Mon, 2003-10-13 at 16:26, Alex Deucher wrote: perhaps the limit is actually 2047? No, the RE_WIDTH_HEIGHT register takes 11 bits for the coordinates of the rightmost column and bottommost line. There may be off-by-one errors in the code though... perhaps it is bandwidth. I agree with you that's unlikely. I downloaded the newest version of xscreensaver last night. the new behavior is to create 2 instances of the GL hack based on the xinerama info and display one on head head. the hack running on the first head displays fine; the one running on the second head shows the corruption. So it seems to have something to do with 2048. It wouldn't be as simple as clears not working (properly) = 2048, would it? Can you capture the problem in screenshots? -- 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] DXTC/S3TC support for Radeons?
Hello all, I've been wondering whether DXTC/S3TC will be implemented in the DRI (Radeon) drivers. I got an ATI Radeon Mobility M9 Lf (AGP). I haven't been able to find any info in this topic on the DRI Wiki. # ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. OpenGL renderer relies on DXTC/S3TC support. History: Exiting due to error # glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read, GLX_SGIS_multisample client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_NV_vertex_array_range, GLX_MESA_agp_offset GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20020827 AGP 4x x86/MMX TCL OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x25 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x29 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2b 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x2c 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x2d 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2e 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2f 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x30 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x31 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x32 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow Could any of you share some info on this with me/us? Thanks a lot. Regs, Csan alias Janos Holanyi Debian Group leader - Association of Hungarian Linux Users URL: http://debian.linux.hu/ Email: csani AT lme.linux.hu gpg --keyserver hkp://pgp.mit.edu --recv-keys 82CBB661 --- 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] DXTC/S3TC support for Radeons?
this is a patent issue: http://dri.sourceforge.net/cgi-bin/moin.cgi/S3TC --- Csan [EMAIL PROTECTED] wrote: Hello all, I've been wondering whether DXTC/S3TC will be implemented in the DRI (Radeon) drivers. I got an ATI Radeon Mobility M9 Lf (AGP). I haven't been able to find any info in this topic on the DRI Wiki. # ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. OpenGL renderer relies on DXTC/S3TC support. History: Exiting due to error # glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read, GLX_SGIS_multisample client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_NV_vertex_array_range, GLX_MESA_agp_offset GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20020827 AGP 4x x86/MMX TCL OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x25 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x29 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2b 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x2c 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x2d 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2e 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2f 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x30 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x31 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x32 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow Could any of you share some info on this with me/us? Thanks a lot. Regs, __ 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 Mon, Oct 13, 2003 at 06:56:32AM -0700, Alex Deucher wrote: Can you clarify what you tried and what the problem is? When I restart the 'new' (with MergedFB) XFree86 X server binary with the old XF86Config (attached) I get a flickering screen with a resolution that is obviously below what I usually set - but 'xdpyinfo' displays the parameters that I usually expect (but are not present). I attached the X server log file '.0' with flickering screen and Option MergedFB false '.1' with this option put into the XF86Config, which clears the situation for me ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- XF86Config.bz2 Description: Binary data XFree86.0.log.bz2 Description: Binary data XFree86.1.log.bz2 Description: Binary data
Re: [Dri-devel] weird corruption with r200
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 16:26, Alex Deucher wrote: perhaps the limit is actually 2047? No, the RE_WIDTH_HEIGHT register takes 11 bits for the coordinates of the rightmost column and bottommost line. There may be off-by-one errors in the code though... Yeah, that's what I thought... perhaps it is bandwidth. I agree with you that's unlikely. I downloaded the newest version of xscreensaver last night. the new behavior is to create 2 instances of the GL hack based on the xinerama info and display one on head head. the hack running on the first head displays fine; the one running on the second head shows the corruption. So it seems to have something to do with 2048. It wouldn't be as simple as clears not working (properly) = 2048, would it? Can you capture the problem in screenshots? That sounds right. because the 3D image shows up correctly. it's like looking through a mesh of bits of old 3d objects (colored the same as the background) with the new 3D scene rendering correctly behind it. I'll try ang grab a screenshot tonight. Alex __ 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] DXTC/S3TC support for Radeons?
On Mon, 2003-10-13 at 17:35, Csan wrote: # ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. OpenGL renderer relies on DXTC/S3TC support. This requirement has been lifted in current versions of UT2003... OpenGL renderer string: Mesa DRI R200 20020827 AGP 4x x86/MMX TCL OpenGL version string: 1.2 Mesa 4.0.4 ... but it won't work well if at all with a 3D driver from XFree86 4.3, you'll have to get a new one from DRI or XFree86 CVS. -- 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
Re: [Dri-devel] Major mergedFB rework committed to CVS
On Mon, 13 Oct 2003, Alex Deucher wrote: hmmm... Have you ever gotten mergedfb working under freebsd? Last night was the first time I tried, so no :-) I've never tested on freebsd. can you send your log? http://memory.visualtech.com/XFree86.0.log Same config file (minus a few changes to the mouse section) and same source tree works on the same machine under Linux :-) Adam Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Alright... You can ignore the unresolved symbol messages. That was my mistake. However, the X server is still crashing under FreeBSD with the MergedFB option enabled. Adam On Mon, 13 Oct 2003, Adam K Kirchhoff wrote: Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher 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. Alex __ 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 [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2003 at 06:56:32AM -0700, Alex Deucher wrote: Can you clarify what you tried and what the problem is? When I restart the 'new' (with MergedFB) XFree86 X server binary with the old XF86Config (attached) I get a flickering screen with a resolution that is obviously below what I usually set - but 'xdpyinfo' displays the parameters that I usually expect (but are not present). That's what I'm not clear on. when you say XFree86 X server binary do you mean /usr/X11R6/bin/XFree86 or radeon_drv.o? I assume you mean the latter. /usr/X11R6/bin/XFree86 has no mergedfb specific code in it. that is all taken care of in the driver. I attached the X server log file '.0' with flickering screen and Option MergedFB false '.1' with this option put into the XF86Config, which clears the situation for me ! I'll take a look at this tonight. Alex __ 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] DXTC/S3TC support for Radeons?
Quoting Alex Deucher [EMAIL PROTECTED]: this is a patent issue: http://dri.sourceforge.net/cgi-bin/moin.cgi/S3TC Argh, how could I have missed that one! :| Thank you. Bad news... but there's hope according to what Michel Daenzer wrote. Regs, Csan alias Janos Holanyi Debian Group leader - Association of Hungarian Linux Users URL: http://debian.linux.hu/ Email: csani AT lme.linux.hu gpg --keyserver hkp://pgp.mit.edu --recv-keys 82CBB661 --- 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] DXTC/S3TC support for Radeons?
Quoting Michel Dänzer [EMAIL PROTECTED]: On Mon, 2003-10-13 at 17:35, Csan wrote: # ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. OpenGL renderer relies on DXTC/S3TC support. This requirement has been lifted in current versions of UT2003... Uhm, I wonder if the latest demo patch also lifts it... (If not, do any of UT2003 developers read this? Could we please have a S3TC-free demo version also? Thanks a lot...) OpenGL renderer string: Mesa DRI R200 20020827 AGP 4x x86/MMX TCL OpenGL version string: 1.2 Mesa 4.0.4 ... but it won't work well if at all with a 3D driver from XFree86 4.3, you'll have to get a new one from DRI or XFree86 CVS. Thanks for the info! Software libre enthusiast So true! ;] Regs, Csan alias Janos Holanyi Debian Group leader - Association of Hungarian Linux Users URL: http://debian.linux.hu/ Email: csani AT lme.linux.hu gpg --keyserver hkp://pgp.mit.edu --recv-keys 82CBB661 --- 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, 13 Oct 2003, Alex Deucher wrote: it seems to crash while validaing the modes on the second head. Which is odd since, if I turn off mergedfb and just use normal xinerama, it works fine, it has no problems validating the modes. I don't know why it should work on linux but not freebsd. you might try turning off DCC and EDID. perhaps those functions are causing a problem on freebsd, although it they wokred ok the first head, they should work on the second. Option noddc true Option IgnoreEDID true Option MonitorLayout CRT, CRT I was already using the MonitorLayout option, and I just tried the noddc option and the IgnoreEDID option. Neither worked. You can also try adjusting the DDC mode: Option DDCMode I just tried with it set to on and off. Neither worked. Adam Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Mon, 13 Oct 2003, Alex Deucher wrote: hmmm... Have you ever gotten mergedfb working under freebsd? Last night was the first time I tried, so no :-) I've never tested on freebsd. can you send your log? http://memory.visualtech.com/XFree86.0.log Same config file (minus a few changes to the mouse section) and same source tree works on the same machine under Linux :-) Adam Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Alright... You can ignore the unresolved symbol messages. That was my mistake. However, the X server is still crashing under FreeBSD with the MergedFB option enabled. Adam On Mon, 13 Oct 2003, Adam K Kirchhoff wrote: Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher 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. Alex __ 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 --- 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] DXTC/S3TC support for Radeons?
Uhm, I wonder if the latest demo patch also lifts it... No. (If not, do any of UT2003 developers read this? Could we please have a S3TC-free demo version also? Thanks a lot...) The UT2004 demo will work without S3TC support... and FWIW, without OpenGL support as well as we're including a software renderer again. -- Daniel, Epic Games Inc. --- 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
When the X server is running it is all in memory. when you copy a never version over the existing install, it just copies over the files. The new files aren't used until you restart the X server. upon restarting you are then loading the new X server (XFree86) which then loads the radeon_drv.o driver to drive your hardware. somehow validating the mode for crtc2 must be messing up the mode for crtc1. I rewrote some of that code, so it's possible I messed something up. Alex --- Martin Spott [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2003 at 09:03:38AM -0700, Alex Deucher wrote: That's what I'm not clear on. when you say XFree86 X server binary do you mean /usr/X11R6/bin/XFree86 or radeon_drv.o? I assume you mean the latter. /usr/X11R6/bin/XFree86 has no mergedfb specific code in it. that is all taken care of in the driver. Doh I really mean /usr/X11R6/bin/XFree86 - how would I reload radeon_drv.o on a running X server ? See: 1.) I'm running last week's build at [EMAIL PROTECTED] _after_ the config-branch merge (X server restart after installing). Everything is fine. 2.) I'm compiling todays CVS and install it _over_ last week's build - the X server remains running. Still everything's fine, FlightGear runs very nice. 3.) I'm restarting the X server and see [EMAIL PROTECTED] or so. 4.) I add your Option MergedFB false into XF86Config and restarting the X server makes me happy, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- __ 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
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Mon, 13 Oct 2003, Alex Deucher wrote: it seems to crash while validaing the modes on the second head. Which is odd since, if I turn off mergedfb and just use normal xinerama, it works fine, it has no problems validating the modes. they use different validation routines. I ought to rewrite the crtc2 routine, but I haven't had a chance. the current one is based on the old clone mode validation routine. Still, I'm not sure why it would work on linux and not freebsd. I don't know why it should work on linux but not freebsd. you might try turning off DCC and EDID. perhaps those functions are causing a problem on freebsd, although it they wokred ok the first head, they should work on the second. Option noddc true Option IgnoreEDID true Option MonitorLayout CRT, CRT I was already using the MonitorLayout option, and I just tried the noddc option and the IgnoreEDID option. Neither worked. You can also try adjusting the DDC mode: Option DDCMode I just tried with it set to on and off. Neither worked. Also make sure you specify the virtual size in the screen section of your config file. Adam Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Mon, 13 Oct 2003, Alex Deucher wrote: hmmm... Have you ever gotten mergedfb working under freebsd? Last night was the first time I tried, so no :-) I've never tested on freebsd. can you send your log? http://memory.visualtech.com/XFree86.0.log Same config file (minus a few changes to the mouse section) and same source tree works on the same machine under Linux :-) Adam Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Alright... You can ignore the unresolved symbol messages. That was my mistake. However, the X server is still crashing under FreeBSD with the MergedFB option enabled. Adam On Mon, 13 Oct 2003, Adam K Kirchhoff wrote: Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher 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. Alex __ 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 672] XFree86 hangs when DRI enabled on a Radeon 7500 PCI
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=672 --- Additional Comments From [EMAIL PROTECTED] 2003-13-10 14:14 --- I'm sorry. I don't have the card anymore. Since I couldn't get it working in a timely fashion, I had to dispose of it. -- 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] DXTC/S3TC support for Radeons?
Daniel Vogel wrote: Uhm, I wonder if the latest demo patch also lifts it... No. I respectfully disagree. The 2206 demo works just fine without s3tc here :-) The UT2004 demo will work without S3TC support... and FWIW, without OpenGL support as well as we're including a software renderer again. Interesting. Haven't seen a first person shooter with a software renderer for quite some time. Maybe interesting if you have a 3.8Ghz Prescott but only a Extreme Graphics igp, though I think the igp should still be faster. 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, 13 Oct 2003, Alex Deucher wrote: --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Mon, 13 Oct 2003, Alex Deucher wrote: it seems to crash while validaing the modes on the second head. Which is odd since, if I turn off mergedfb and just use normal xinerama, it works fine, it has no problems validating the modes. they use different validation routines. I ought to rewrite the crtc2 routine, but I haven't had a chance. the current one is based on the old clone mode validation routine. Still, I'm not sure why it would work on linux and not freebsd. I don't know why it should work on linux but not freebsd. you might try turning off DCC and EDID. perhaps those functions are causing a problem on freebsd, although it they wokred ok the first head, they should work on the second. Option noddc true Option IgnoreEDID true Option MonitorLayout CRT, CRT I was already using the MonitorLayout option, and I just tried the noddc option and the IgnoreEDID option. Neither worked. You can also try adjusting the DDC mode: Option DDCMode I just tried with it set to on and off. Neither worked. Also make sure you specify the virtual size in the screen section of your config file. It's been set to 2048 768 the entire time. Adam --- 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] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- 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] DXTC/S3TC support for Radeons?
I respectfully disagree. The 2206 demo works just fine without s3tc here :-) D'oh! Forgot about that :) Interesting. Haven't seen a first person shooter with a software renderer for quite some time. Maybe interesting if you have a 3.8Ghz You can download a version of the software renderer for UT2003 from unreal.epicgames.com albeit Windows only and it's an early version with a lot of minor caveats that have mostly been fixed since then. Prescott but only a Extreme Graphics igp, though I think the igp should still be faster. The software renderer (we use RAD's Pixomatic) actually outperforms a TNT2 in certain cases and I guess will see more use on Linux than on Windows. -- Daniel, Epic Games Inc. --- 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 09: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. you might try turning off DCC and EDID. perhaps those functions are causing a problem on freebsd, although it they wokred ok the first head, they should work on the second. Option noddc true Option IgnoreEDID true Option MonitorLayout CRT, CRT You can also try adjusting the DDC mode: Option DDCMode Alex 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] --- 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] DXTC/S3TC support for Radeons?
Quoting Roland Scheidegger [EMAIL PROTECTED]: Daniel Vogel wrote: Uhm, I wonder if the latest demo patch also lifts it... No. I respectfully disagree. The 2206 demo works just fine without s3tc here :-) Wow! Does that mean that I have the *chance* of checking out this game without spending bucks on the full version first?! Like, the whole idea of a demo would be to be able to test it and see if I like it and want to invest in the full version... wouldn't it? =] Roland, could you please share the necessary pieces of info with me on how to make ut2003_demo run on my Linux laptop with a Radeon M9? TIA The UT2004 demo will work without S3TC support... and FWIW, without OpenGL support as well as we're including a software renderer again. Sounds great! Thanks. Regs, Csan alias Janos Holanyi Debian Group leader - Association of Hungarian Linux Users URL: http://debian.linux.hu/ Email: csani AT lme.linux.hu gpg --keyserver hkp://pgp.mit.edu --recv-keys 82CBB661 --- 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] DXTC/S3TC support for Radeons?
Quoting Roland Scheidegger [EMAIL PROTECTED]: Daniel Vogel wrote: Uhm, I wonder if the latest demo patch also lifts it... No. I respectfully disagree. The 2206 demo works just fine without s3tc here :-) Wow! Does that mean that I have the *chance* of checking out this game without spending bucks on the full version first?! Like, the whole idea of a demo would be to be able to test it and see if I like it and want to invest in the full version... wouldn't it? =] Roland, could you please share the necessary pieces of info with me on how to make ut2003_demo run on my Linux laptop with a Radeon M9? TIA The UT2004 demo will work without S3TC support... and FWIW, without OpenGL support as well as we're including a software renderer again. Sounds great! Thanks. Regs, Csan alias Janos Holanyi Debian Group leader - Association of Hungarian Linux Users URL: http://debian.linux.hu/ Email: csani AT lme.linux.hu gpg --keyserver hkp://pgp.mit.edu --recv-keys 82CBB661 --- 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] DXTC/S3TC support for Radeons?
And all this will run on linux even though you guys are going to MS publishing after UT 2004? *sly smile* -James Daniel Vogel wrote: Uhm, I wonder if the latest demo patch also lifts it... No. (If not, do any of UT2003 developers read this? Could we please have a S3TC-free demo version also? Thanks a lot...) The UT2004 demo will work without S3TC support... and FWIW, without OpenGL support as well as we're including a software renderer again. -- Daniel, Epic Games Inc. --- 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] Snapshots
Just to let everybody know that all snapshots are failing ATM. I get the following error on all logs: gcc -m32 -o xf86cfg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -L../../../../../exports/lib -L/usr/X11R6/lib accessx.ocards.o config.ocard-cfg.o expert.o help.o interface.o keyboard-cfg.o libc_wrapper.o loader.o loadmod.o monitor-cfg.o mouse-cfg.o options.o screen-cfg.oscreen.o startx.ostubs.o text-mode.o vidmode.o xf86config.o -lxkbui -lxkbfile -lxf86config -lXxf86misc -lXxf86vm -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXpm -L../loader -lxloader -L../dummylib -ldummy -rdynamic -ldl -lXext -lX11 -lncurses -lm -Wl,-rpath-link,../../../../../exports/lib help.o(.text+0x9f): In function `Help': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:81: undefined reference to `XawTextSourceClearEntities' help.o(.text+0x3bd): In function `StartHelp': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:141: undefined reference to `XawTextSinkConvertPropertyList' help.o(.text+0x94a): In function `Html_ModeEnd': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:536: undefined reference to `XawTextSourceClearEntities' help.o(.text+0xce4): In function `Html_AddEntities': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:637: undefined reference to `XawTextSinkCopyProperty' help.o(.text+0xd18):/home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:641: undefined reference to `XawTextSinkGetProperty' help.o(.text+0xd34):/home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:641: undefined reference to `XawTextSinkCombineProperty' help.o(.text+0xd63):/home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:651: undefined reference to `XawTextSinkAddProperty' help.o(.text+0xe75):/home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:687: undefined reference to `XawTextSourceAddEntity' help.o(.text+0xeea):/home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:691: undefined reference to `XawTextSourceAddEntity' help.o(.text+0xf4c):/home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:649: undefined reference to `XawTextSinkCombineProperty' help.o(.text+0xf6e):/home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:644: undefined reference to `XawTextSinkCombineProperty' help.o(.text+0x1065): In function `Html_Commit': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:774: undefined reference to `XawTextSourceAddEntity' help.o(.text+0x2dd3): In function `Html_AArgs': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:1583: undefined reference to `XawTextSinkCopyProperty' help.o(.text+0x2e37): In function `Html_FontArgs': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:1606: undefined reference to `XawTextSinkCopyProperty' collect2: ld returned 1 exit status I really don't know what changed on my system to cause this, but it seems better to upload to XFree 4.3.0 on Debian experimental to avoid rebuilding all the X server. This will take a couple of days so no snapshots until then. Jose Fonseca --- 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] Snapshots
On Tue, 2003-10-14 at 00:37, Jos Fonseca wrote: Just to let everybody know that all snapshots are failing ATM. I get the following error on all logs: gcc -m32 -o xf86cfg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -L../../../../../exports/lib -L/usr/X11R6/lib accessx.o cards.o config.ocard-cfg.o expert.o help.o interface.o keyboard-cfg.o libc_wrapper.o loader.o loadmod.o monitor-cfg.o mouse-cfg.o options.o screen-cfg.oscreen.o startx.ostubs.o text-mode.o vidmode.o xf86config.o -lxkbui -lxkbfile -lxf86config -lXxf86misc -lXxf86vm -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXpm -L../loader -lxloader -L../dummylib -ldummy -rdynamic -ldl -lXext -lX11 -lncurses -lm -Wl,-rpath-link,../../../../../exports/lib help.o(.text+0x9f): In function `Help': /home/jfonseca/projects/dri/snapshots/build/HEAD/xc/programs/Xserver/hw/xfree86/xf86cfg/help.c:81: undefined reference to `XawTextSourceClearEntities' You don't need xf86cfg for the snapshots, do you? I always build with #define BuildXFree86ConfigTools NO in host.def (maybe it should be that way in the repository?). -- 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] dri cvs needs newest expat?
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? 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
[Dri-devel] texture problem with i810
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? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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] weird corruption with r200
I've uploaded some screenshots as an example: http://www.botchco.com/alex/2048-error/ the new version of xscreensaver displays a separate instance on each head of a xinerama desktop. so in this case only the context running up again the 2048 limit (the right side) shows the error. When I turn off xinerama or run an older version of xscreensaver the corruption shown on the right side of the above images shows across the entire screen. Looks like a clearing problem. you can see there seems to be remnants of old whales and glxgears overlayed on the new scene. Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: ... I downloaded the newest version of xscreensaver last night. the new behavior is to create 2 instances of the GL hack based on the xinerama info and display one on head head. the hack running on the first head displays fine; the one running on the second head shows the corruption. So it seems to have something to do with 2048. It wouldn't be as simple as clears not working (properly) = 2048, would it? Can you capture the problem in screenshots? __ 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
