[Dri-devel] Major mergedFB rework committed to CVS
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
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] 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] 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] 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] 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] Major mergedFB rework committed to CVS
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 --- 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
Re: [Dri-devel] Major mergedFB rework committed to CVS
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 ! -- --- 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 __
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 O
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
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] 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 Dänzer \ 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
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
Re: [Dri-devel] Major mergedFB rework committed to CVS
Hey guys, That did it. I moved libint10.a out of the way on my linux installation, and now X is failing to start just as it did under FreeBSD (while validating modes on the second head). So, in theory, you should be able to reproduce the problem really easily, Alex, by moving that file, too. Of course, I'm more than willing to test or try anything on my end. Adam On Mon, 13 Oct 2003, Eric Anholt wrote: > 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 > --- 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 21:58, Alex Deucher wrote: > > 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. So you are no longer actually emulating the former clone mode. Reverting that sounds like a very good idea. Experimental changes should probably be done on a branch. -- Earthling Michel Dänzer \ 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
Michel Dänzer wrote: On Tue, 2003-10-14 at 21:58, Alex Deucher wrote: 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. So you are no longer actually emulating the former clone mode. Reverting that sounds like a very good idea. Experimental changes should probably be done on a branch. I have to say I agree with Michel here. In hindsight, this work should have been done on a branch to start with -- the trunk isn't the place to be debugging new code. I'm not sure how much work is left in this, but I'm coming to share the opinion that it is still worthwhile to move it to a branch until the glitches are ironed out. 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
I'll take a look at it if I get some free time this week. Alex --- Adam K Kirchhoff <[EMAIL PROTECTED]> wrote: > > Hey guys, > > That did it. I moved libint10.a out of the way on my linux > installation, and now X is failing to start just as it did under > FreeBSD > (while validating modes on the second head). > > So, in theory, you should be able to reproduce the problem really > easily, Alex, by moving that file, too. Of course, I'm more than > willing > to test or try anything on my end. > > Adam > > On Mon, 13 Oct 2003, Eric Anholt wrote: > > > 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 > > > __ 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
It's still emulating the old clone mode. it just uses the mergefb clone mode rather than the old clone mode since there were just about the same code-wise. Clone mode was on by default in the old radeon driver, so the mergedfb equivalent is on by default in mergedfb. the reason for the default to clone mode was to prevent damage to external monitors because by default the chip uses crtc1 to drive both heads. if the secondary monitor can't handle the signal it could damage the monitor. hence clone mode looks at the DDC/EDID info and determines the monitor's capabilites. if it can't handle the mode it shuts it off. The problem is that the hardware is kind of quirky (especially with OEM stuff) when it comes to DDC and which head is which. I can switch back to the old order in the mean time, however, I'm not sure if it is any more or less reliable than the current code. both work fine on my hardware. testing will prove what works best I suppose. Alex --- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Tue, 2003-10-14 at 21:58, Alex Deucher wrote: > > > > 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. > > So you are no longer actually emulating the former clone mode. > Reverting > that sounds like a very good idea. Experimental changes should > probably > be done on a branch. > > > -- > 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] Major mergedFB rework committed to CVS
That's fine with me. we can revert back to xfree86 CVS for the trunk and I can move to a branch. I wouldn't have put it on the trunk if I had know the mode stuff was cause so much trouble, but then again, it's been working fine for me and those who initially tested it, so I need to more testers to find the bugs :) if we move to a branch, perhaps we could add it to the snapshots? Alex --- Keith Whitwell <[EMAIL PROTECTED]> wrote: > Michel Dänzer wrote: > > On Tue, 2003-10-14 at 21:58, Alex Deucher wrote: > > > >>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. > > > > > > So you are no longer actually emulating the former clone mode. > Reverting > > that sounds like a very good idea. Experimental changes should > probably > > be done on a branch. > > > > I have to say I agree with Michel here. In hindsight, this work > should have > been done on a branch to start with -- the trunk isn't the place to > be > debugging new code. > > I'm not sure how much work is left in this, but I'm coming to share > the > opinion that it is still worthwhile to move it to a branch until the > glitches > are ironed out. > > Keith > __ 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
Alex Deucher wrote: That's fine with me. we can revert back to xfree86 CVS for the trunk and I can move to a branch. I wouldn't have put it on the trunk if I had know the mode stuff was cause so much trouble, but then again, it's been working fine for me and those who initially tested it, so I need to more testers to find the bugs :) I'm sympathetic to this argument: People generally don't bother with downloading stuff on a branch, so it doesn't get anything like the testing exposure as the trunk code. if we move to a branch, perhaps we could add it to the snapshots? That's a reasonable idea - but it still wouldn't have caught the freebsd problems. 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
perhaps for the time being I can set mergedfb to default to "false" rather than the "true" clone mode it does now. that should prevent the mergedfb code paths from being taken and those that want to try it can simply turn it on. I don't think anyone has had a problem with it turned off. speak up if you do... Alex --- Keith Whitwell <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > That's fine with me. we can revert back to xfree86 CVS for the > trunk > > and I can move to a branch. I wouldn't have put it on the trunk if > I > > had know the mode stuff was cause so much trouble, but then again, > it's > > been working fine for me and those who initially tested it, so I > need > > to more testers to find the bugs :) > > I'm sympathetic to this argument: People generally don't bother with > > downloading stuff on a branch, so it doesn't get anything like the > testing > exposure as the trunk code. > > > if we move to a branch, perhaps we could add it to the snapshots? > > That's a reasonable idea - but it still wouldn't have caught the > freebsd problems. > > Keith > __ 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 Wed, 2003-10-15 at 22:12, Alex Deucher wrote: > perhaps for the time being I can set mergedfb to default to "false" That's probably a good idea, but then it should default to clone mode as pre-MergedFB. Driving both heads with a single CRTC is nasty. -- Earthling Michel Dänzer \ 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
--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Wed, 2003-10-15 at 22:12, Alex Deucher wrote: > > perhaps for the time being I can set mergedfb to default to "false" > > That's probably a good idea, but then it should default to clone mode > as > pre-MergedFB. Driving both heads with a single CRTC is nasty. > > ugh... that's gonna take some work... I eliminated all the old clone code because it was mostly duplicated code paths. when I initially wrote mergedfb, I had left in all the old clone stuff as well, but everyone who reviewed the code said it was duplicated and should be eliminated if I wanted it to be accepted upstream... I guess it can go back... __ 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 Wed, 2003-10-15 at 22:58, Alex Deucher wrote: > --- Michel Dnzer <[EMAIL PROTECTED]> wrote: > > On Wed, 2003-10-15 at 22:12, Alex Deucher wrote: > > > perhaps for the time being I can set mergedfb to default to "false" > > > > That's probably a good idea, but then it should default to clone mode > > as pre-MergedFB. Driving both heads with a single CRTC is nasty. > > ugh... that's gonna take some work... I eliminated all the old clone > code because it was mostly duplicated code paths. when I initially > wrote mergedfb, I had left in all the old clone stuff as well, but > everyone who reviewed the code said it was duplicated and should be > eliminated if I wanted it to be accepted upstream... I was probably one of them, but I was thinking along the lines of reusing the existing code, not dumping it. :) -- Earthling Michel Dänzer \ 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
--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Wed, 2003-10-15 at 22:58, Alex Deucher wrote: > > --- Michel Dnzer <[EMAIL PROTECTED]> wrote: > > > On Wed, 2003-10-15 at 22:12, Alex Deucher wrote: > > > > perhaps for the time being I can set mergedfb to default to > "false" > > > > > > That's probably a good idea, but then it should default to clone > mode > > > as pre-MergedFB. Driving both heads with a single CRTC is nasty. > > > > ugh... that's gonna take some work... I eliminated all the old > clone > > code because it was mostly duplicated code paths. when I initially > > wrote mergedfb, I had left in all the old clone stuff as well, but > > everyone who reviewed the code said it was duplicated and should be > > eliminated if I wanted it to be accepted upstream... > > I was probably one of them, but I was thinking along the lines of > reusing the existing code, not dumping it. :) > > It is reused :) it's just that I got rid of alot of the "if (info->Clone)" and replaced them with "if (info->MergedFB)". A lot of stuff had to be nixed or extended to handle modes besides clone (leftOf, rightof, etc.) and the data structures that hold the relevant data changed a bit. __ 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
Alex Deucher <[EMAIL PROTECTED]> wrote: > I can switch back to the old order in the mean time, however, I'm not > sure if it is any more or less reliable than the current code. both > work fine on my hardware. I just rebuilt the stuff with a CVS checkout from one hour before now. When I do _not_ explicitly _disable_ MergedFB in XG86Config, the X server spits out this to the log: (II) RADEON(0): Generating MergedFB mode list (II) RADEON(0): No MetaModes given, linking first modes by default (EE) RADEON(0): Failed to parse MetaModes or no modes found. MergeFB mode disabled. (--) RADEON(0): MergedFB: Virtual width 1152 (--) RADEON(0): MergedFB: Virtual height 864 This is exactly the resolution that I expect on my one and only screen of a Radeon7500 - but it does not show up, 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
Yeah, I've noticed that as well. If I only comment out the lines regarding MergedFB, it still assumes I want to use MergedFB. I need to explicity tell it not to. Adam On 16 Oct 2003, Martin Spott wrote: > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > I can switch back to the old order in the mean time, however, I'm not > > sure if it is any more or less reliable than the current code. both > > work fine on my hardware. > > I just rebuilt the stuff with a CVS checkout from one hour before now. > When I do _not_ explicitly _disable_ MergedFB in XG86Config, the X > server spits out this to the log: > > (II) RADEON(0): Generating MergedFB mode list > (II) RADEON(0): No MetaModes given, linking first modes by default > (EE) RADEON(0): Failed to parse MetaModes or no modes found. MergeFB mode disabled. > (--) RADEON(0): MergedFB: Virtual width 1152 > (--) RADEON(0): MergedFB: Virtual height 864 > > > This is exactly the resolution that I expect on my one and only screen > of a Radeon7500 - but it does not show up, > > 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 > --- 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
