From: "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca>
To: Magnus Damm <damm@opensource.se>,
Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: aty128fb and EDID
Date: Mon, 10 Feb 2003 08:16:36 -0500 [thread overview]
Message-ID: <200302100816.36075.kevin.hendricks@sympatico.ca> (raw)
In-Reply-To: <20030210111453.52322aba.damm@opensource.se>
Hi,
I found the code to decode the full block from a variety of source (X11 had
some of it). The problem is the "established timings" block was empty in
my EDID block (or I made a big mistake someplace).
My primary concern was just getting my DFP to work at all at the time.
I will dig up what I have about timings and post it if anyone wants it.
Kevin
On February 10, 2003 05:14, Magnus Damm wrote:
> > > 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.p
>enguinppc.org&lr=
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-02-10 13:16 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
2003-02-10 13:16 ` Kevin B. Hendricks [this message]
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=200302100816.36075.kevin.hendricks@sympatico.ca \
--to=kevin.hendricks@sympatico.ca \
--cc=damm@opensource.se \
--cc=geert@linux-m68k.org \
--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).