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
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 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
Michel Dnzer 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 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
--- 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 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
--- 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
On Mon, 2003-10-13 at 18:14, Alex Deucher wrote: it seems to crash while validaing the modes on the second head. I don't know why it should work on linux but not freebsd. Maybe your code makes assumptions which are true on Linux but false on FreeBSD, e.g. something related to memory allocation? Of course, a backtrace would be better than guessing what it could be. :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
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
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
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] 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
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
