I, for one, welcome our new SEG OverLords,

Yup, I know this one's been making the rounds, and it's been up the
RFE path before, and the corresponding BZ is closed as fixed in
RHEL5.2.  However, it's still broken as it's still forcing 16bpp. So,
here comes the escalation template. Not sure if this should be marked
"Regression" or not, but whatever you want to call it, "only
partially working" is appropriate.

General Escalation Information
===========================================================================
State the problem:

  1. Provide time and date of the problem

  Not applicable, happens every time on RHEL5.3 you start X and have
  a mga200e card with 8MB vram.

  2. Indicate the platform(s) (architectures) the problem is being
    reported against.

  x86 / x86_64 (but probably not limited to)

  3. Provide clear and concise problem description as it is
     understood at the time of escalation
     * Observed behavior

  (--) MGA(0): Chipset: "mgag200 SE A PCI"
  (EE) MGA(0): Forcing 16bpp on G200SE due to low memory.
  (--) MGA(0): VideoRAM: 8128 kByte

     * Desired behavior

  Allow 8, 15, 16 and 24 bpp without real restrictions. Might be a
  case, as on the RHEL4 issue, to lock to 16bpp if a Kronos1 (1.7MB
  vram), but with 8MB, we can allow 24bpp I think...

  4. State specific action requested of SEG

  Run this up to Engineering, f.a.o. Ajax. I think Chris Ward has
  been working on this as well for the RHEL4 issue (126881).

  5. State whether or not a defect in the product is suspected

  Yes, defect suspected.

     * Provide Bugzilla if one already exists

  None found (so far).

  6. If there is a proposed patch, make sure it is in unified diff
     format (diff -pruN)

  No patch.

  8. This is especially important for severity one and two
     issues. What is the impact to the customer when they experience
     this problem?

  Hard one to state, but probably akin to your car having four gears,
  and you are only allowed to use one of them, the third one,
  regardless of how many passangers you have.

  We are arbitrarily overriding the requested depth from xorg.conf in
  this driver, even when no real reason to do so.

Provide supporting info

  1. State other actions already taken in working the problem:

    * tech-list, google searches, fulltext, consulting with another
      engineer

  Having worked on the problem since July 2007....

    * Provide any relevant data found

  It's aaaaall in the issue. :) And in IT#282593. And for RHEL4 in
  IT#126881 (and probably more to boot)

  2. Attach sosreport

  If this really is required, I'll get you one from the RX200S5 in
  the Lab. The xorg.conf snippet in
  https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=282593&gid=1011&view_type=lifoall#eid_2890306
  might give enough.

  3. Attach other supporting data

  ...

  4. Provide issue repro information:
     * List steps or...

  1. Obtain a system that use the mga graphics driver
  2. create a plain xorg.conf that requests 24bpp Depth
  3. startx
  4. peer in to /var/log/Xorg.0.log and notice that the driver
     have blatantly ignored your request for 24bpp, instead
     giving you 16bpp.

     * ...reference the specific ticket update which contains the
       steps.

     * Provide location and access information for repro machine, if
       available

  5. List any known hot-fix packages on the system

  Not applicable. Happens on a clean RHEL5.3 x86_64 install.

  6. List any customer applied changes from the last 30 days

  Other than clean install and running s-c-d? None.

===========================================================================

This appears to be a regression