linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Magnus Damm <damm@opensource.se>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: kevin.hendricks@sympatico.ca, linuxppc-dev@lists.linuxppc.org
Subject: Re: aty128fb and EDID
Date: Mon, 10 Feb 2003 11:14:53 +0100	[thread overview]
Message-ID: <20030210111453.52322aba.damm@opensource.se> (raw)
In-Reply-To: <Pine.GSO.4.21.0302101034180.25020-100000@vervain.sonytel.be>


> > Steal the code from the radeon dirver in the kernel.  It finds and parses
> > the EDID block in OF for ppc linux systems for LCD.

Yes, thanks. That's the short-term solution.
The problem is that the radeon driver only parses the "detail timings".
I want to support all timings including "established timings" and
"detailed timings".
And then it gets more complex...

> I guess you actually meant:
>
> | Move the code out of the radeon driver and make it sufficiently generic so it
> | can be used by the aty128 and other drivers?

Yes. Here's my grand plan:

1. Rearrange modes from modedb.c/macmodes.c into separate files for:
   * Standard VGA modes
   * Tweaked VGA modes (modex)
   * VESA modes
   * Archtecture-specific modes
   (* A mode calculator)
   This includes adding add/remove functions to be able to insmod/rmmod
   modules runtime.

2. Add EDID parsing code.
   The code should be able to list "established timings" and "standard timings".
   Modes should be built from "detail timings".
   Getting the EDID structure could be done in several ways:
   * Through Open Firmware (mac and maybe others)
   * Through the BIOS
   * Via I2C bitbanging (requires special support by the fb-driver)

3. Add code that gets information from the EDID parser and looks through the
   modes available and then creates a list of supported modes.

4. Add architecture-specific code that looks up the model and then returns a
   list of supported modes. This should be used if the machine doesn't have EDID
   information. (See aty128db.c and machine_is_compatible()).

5. Add code that takes the modes from 3 or 4 above and throws it at the fb-driver
   that looks them through and marks the supported modes with what colour-
   depths that are supported.

6. Add a "mode" variable for each framebuffer.
   This should make it possible to switch between the following states:
   * Safe - only modes that are listed by the monitor are accepted.
   * Standard - old standard modes that might work
   * Expert - funky timings that might blow your monitor
   The "Safe" mode is default.
   I don't know yet how the "mode"-variable should be controlled. /proc?

7. Add support to(/from) vga=ask. The user should be able to switch between
   the modes listed in 6 above.

And then we have VDIF... Feedback is very welcome.

/ magnus

BTW: I found some EDID data here:
http://www.google.com/search?hl=sv&ie=UTF-8&oe=UTF-8&q=EDID+site%3Aftp.penguinppc.org&lr=

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-02-10 10:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-09 23:26 aty128fb and EDID Magnus Damm
2003-02-10  0:40 ` Kevin B. Hendricks
2003-02-10  9:35   ` Geert Uytterhoeven
2003-02-10 10:14     ` Magnus Damm [this message]
2003-02-10 13:16       ` Kevin B. Hendricks
2003-02-10 18:41         ` Dan Burcaw
2003-02-10 18:59           ` Kevin B. Hendricks
2003-02-10 10:34     ` Benjamin Herrenschmidt
2003-02-10 12:36     ` Kevin B. Hendricks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030210111453.52322aba.damm@opensource.se \
    --to=damm@opensource.se \
    --cc=geert@linux-m68k.org \
    --cc=kevin.hendricks@sympatico.ca \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).