--- 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
