Red Hat Bugzilla – Bug 508039
Use 24bpp framebuffer on g200se to avoid bandwidth limit
Last modified: 2013-03-03 21:48:04 EST
Created attachment 349368 [details]
Description of problem:
The g200e SE chipset has a limited bandwidth, causing modes to be rejected in 24 bit depth when using a 32bpp framebuffer.
However, selecting a 24bpp packed framebuffer reduces the induced bandwith and allow the use of modes that were otherwise rejected.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install el4 on a server with a g200se chipset
2. Make sure to use 24 depth
3. start the X server
The desired mode get rejected:
(**) MGA(0): Depth 24, (--) framebuffer bpp 32
(II) MGA(0): Not using default mode "1280x1024" (unknown)
(--) MGA(0): Virtual size is 1280x864 (pitch 1280)
The desired mode is not rejected:
(**) MGA(0): Depth 24, (--) framebuffer bpp 24
(--) MGA(0): Virtual size is 1280x1024 (pitch 1280)
The chipset used (G200e SE) has a limited bandwith and the mode are rejected because the bandwidths induced by these modes witgh frame buffer of 32bppp are too high.
The limitation in bandwidth was introduced by this commit upstream:
For example, with the first timings listed in the Xorg.log file:
Modeline "1280x1024" 108.00 1280 1328 1440 1688 1024 1025 1028 1066
^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^
| | | | |
mode->Clock/1000 -------' | | | |
mode->HDisplay --------------' | | |
mode->HTotal ---------------------------- ' | |
mode->VDisplay -----------------------------------' |
With a 32bpp we have a bandwidth of:
4 * (1280*1024) / (1688*1066) * 108.00 = 314.68
With a 32bpp the mode gets rejected as the resulting bandwith is greater than 256.
But with a 24bpp framebuffer (that this chipset supports):
3 * (1280*1024) / (1688*1066) * 108.00 = 236.00
So the mode would be supported with a 24bpp.
I am attaching a patch for the xorg-x11-drv-mga-1.4.10 that does select a 24bpp packed framebuffer when using a g200e SE chipset by default.
The user can still change the framebuffer depth by using the "DefaultFbBpp" in xorg.conf, but the default is 24bpp for that particular chipset that is limited in bandwidth.
Created attachment 349369 [details]
This patch prefers a 24bpp packed framebuffer by default for the G200e SE chipset to reduce the impact of the limited bandwidth on this hardware.
The default of 32bpp remains unchanged for other chipsets.
This patch is 100% correct for this chip set, and has almost no risk of introducing regressions. You can be certain that Fujitsu and FTS will retest thoroughly with the G200SE, which is the only chip set affected by that patch.
In fact, this patch is more appropriate for our problem (wrong resolutions with G200SE at depth 24) than the one proposed in bug #507536, which is more complex and has more potential for regressions with other chip sets. Applying the patch from 508039 will make the patch from 507536 unnecessary from our point of view.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Event posted on 07-29-2009 11:12am JST by email@example.com
I'd like to inform test package at below, would you please verify it?
Also ,this is blocker for Snapshot 5.
Internal Status set to 'Waiting on Customer'
Status set to: Waiting on Client
This event sent from IssueTracker by firstname.lastname@example.org
Per private comment #25, the UK TAM installed and tested package xorg-x11-drv-mga-1.4.10-4.el5.jx2.x86_64.rpm on a RHEL5.4snap3 machine using the Kronos1 1.7MB chipset and X came up fine on reboot at 1024x768 16bpp. Additionally, he installed xorg-x11-drv-mga-1.4.10-4.el5.jx2.x86_64.rpm on a RHEL5.4snap3 machine using the Kronos2 8MB chipset. The original resolution post-install didn't fit the screen properly but was readable, but using this test package it came up correctly at 1280x1024 24bpp on restarting X. He attached logs for engineering review.
Kevin M. reviewed the *.after logs and they are correctly shrinking the virtual
fb size to allow 1024x768 @ 16bpp. He will have Adam double check his
findings tomorrow (Monday), and assuming they both agree, they will provide a
recommendation to PM about how best to include the updated patch.
Setting to NEEDINFO ajax.
Do we have this driver on a people.page so partners may test it as well?
> Do we have this driver on a people.page so partners may test it as well?
~~ Attention Partners - RHEL 5.4 Snapshot 5 Released! ~~
RHEL 5.4 Snapshot 5 is the FINAL snapshot to be release before RC. It has been
released on partners.redhat.com. If you have already reported your test results,
you can safely ignore this request. Otherwise, please notice that there should be
a fix available now that addresses this particular issue. Please test and report
back your results here, at your earliest convenience.
If you encounter any issues while testing Beta, please describe the
issues you have encountered and set the bug into NEED_INFO. If you
encounter new issues, please clone this bug to open a new issue and
request it be reviewed for inclusion in RHEL 5.4 or a later update, if it
is not of urgent severity. If it is urgent, escalate the issue to your partner manager as soon as possible. There is /very/ little time left to get additional code into 5.4 before GA.
Partners, after you have verified, do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue.
Further questions can be directed to your Red Hat Partner Manager or other
appropriate customer representative.
1916307 build (dist-5E-qu-candidate, RHEL-5:xorg-x11-drv-mga-1_4_10-5_el5): open (x86-004.build.bos.redhat.com) -> closed
Fujitsu, please test using the latest RC1 test build for this package. This is the candidate build for RC1.
Chris, xorg-x11-drv-mga-1.4.10-5.el5 has been verified
for both Kronos1 1.7MB chipset and Kronos2 8MB chipset.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
Requested information was provided in IssueTracker.
This is just to clear the needinfo flag.