|
Bugzilla – Full Text Bug Listing |
| Summary: | Video mode is too high for the ES1000 video ASIC | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Rod Macdonald <rod.macdonald> |
| Component: | X.Org | Assignee: | Stefan Dirsch <sndirsch> |
| Status: | RESOLVED FIXED | QA Contact: | Stefan Dirsch <sndirsch> |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | antonovi, eich, eldho_kuriakose, john_hull, marc.ruehrschneck, mdanzer, mtippett |
| Version: | Alpha 4 | ||
| Target Milestone: | --- | ||
| Hardware: | i386 | ||
| OS: | SuSE Pro 9.2 | ||
| Whiteboard: | |||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
XFree86Config
/var/log/XFree86.0.log Patch for SLES9 Config file for 24bpp test Config file for 24bpp test Log file from 24bp test radeon.tar.bz2 |
||
|
Description
Rod Macdonald
2005-12-15 15:17:19 UTC
Created attachment 60983 [details]
XFree86Config
Created attachment 60985 [details]
/var/log/XFree86.0.log
I wonder why ATI can't take care of this itself, e.g. Hui Yu <hyu@ati.com> is very familiar with the Open Source radeon driver and he has commit rights to X.Org CVS as well and did many patches especially for new chipset support in the past. *** Bug 142143 has been marked as a duplicate of this bug. *** It looks like this needs to be fixed in the opensource driver. Rod, can you forward this to e.g. Hui Yo as Stefan mentioned? Let us know what your thoughts are. Hui Yu is no longer available for investigations on the radeon open source driver. Having said that, another developer at ATI is looking at providing a patch for this problem that will selectively restrict the pixel clock depending on the bpp requested. Essentially the fix will look like this: Limit the pixel clock to 100 MHz at 32bpp 200 MHz at 16bpp 400 Mhz at 8bpp We might need to limit the 8bpp further to meet a specific request for Dell. I'll append a patch as soon as it is ready. Thanks for keeping us up-to-date. Hi Stefan, Could you also apply this patch to SLES 10 since this problem also exists in X.Org I think so. OK, the patch limits the max pll clock by using an empirical formual taken from the ATi Windows driver. We should use it. submitted for STABLE. Fixed in 10.1 Beta > 4. This patch has broken IBM T41p support again completely. Therefore I disabled it for now. See Bug #152473 for details. Bug 152473: ----------- [...] Comment #22 From Stefan Dirsch 2006-02-22 11:26 MST [reply] > > I don't see how rn50-pixelclock-limit.diff could have such an effect - it > > should only have *any* effect with an RN50 card. > It was surprising for me as well ... I'll doublecheck! rn50-pixelclock-limit.diff is not responsible for the hangup on T41p. I reverted this, i.e. I enabled the patch again. Created attachment 70843 [details]
Patch for SLES9
reopen. submitted patch (comment #16) for SLES9-SP4. Regarding the test RPMs provided by Stefan: Date: Wed Mar 1 18:19:54 CET 2006 From: sndirsch@suse.de ftp://ftp.suse.com/pub/people/sndirsch/RPMS/ATI - p_radeon-dell.diff: * fixes wrong mouse position on Dell servers ( Bug #138458) - p_rn50-pixelclock-limit.diff: * Limit pixel clock to model memory bandwidth limits ( Bug #139361, X.Org Bug #5766) - p_radeon-window-panning.diff: * should fix window panning problem ( Bug #151621) =============================================================================== Date: Monday, 6 Mar 2006 From: Rod Macdonald <rmacdona@ati.com> This RPM does limit the ES1000 resolutions sufficiently to eliminate corruption. I tested by setting XF86Config to allow very high resolutions and then ran startx which showed the following: 1. Limit of 1600x1200@73Hz for 8bpp 2. Limit of 1600x1200@73Hz for 16bpp 3. Limit of 1280x960@60Hz for 24bpp Testing was performed on a Dell SC1430 with SLES9 SP3 32b. The result for #3 might be of concern to Dell. I'll attach the config and log files shortly. With RHEL we saw 1280x1024@60Hz for 24bpp. These results should also be verified by Dell. Created attachment 71565 [details]
Config file for 24bpp test
Created attachment 71566 [details]
Config file for 24bpp test
Created attachment 71567 [details]
Log file from 24bp test
(In reply to comment #19)> > > The result for #3 might be of concern to Dell. I'll attach the config and log > files shortly. With RHEL we saw 1280x1024@60Hz for 24bpp. Was that with the same monitor? 1280x1024@60 is 108 Mhz, which is within the limit of 112.5 Mhz that the driver calculated from the memory parameters (and AFAIK Anatoli succeeded in using this mode with a limit of 110 Mhz on RHEL3). There doesn't seem to be a problem here other that 60Hz vrefresh are quite low for CRTs. Going up to 110 or 112 MHz does not increase the frame rate considerably. > Was that with the same monitor? 1280x1024@60 is 108 Mhz, which is within the
> limit of 112.5 Mhz
I reconfigured the monitor settings with Yast and now I get 1280x1024@60Hz for 24bpp. All is well. Thanks,
Stefan, can you tell me if this fix will be in the next update to SLES9? Currently no since other bugs, which I wanted to fix at the same time are not resolved yet (#138458,#151621). > Currently no since other bugs, which I wanted to fix at the same time are
> not resolved yet (#138458,#151621).
Just for the record. #151621 has been resolved fixed meanwhile. #138458 is
still remaining.
Created attachment 87821 [details]
radeon.tar.bz2
Updated driver for testing.
|