Hi Ben,
Sounds like the right solution to me. I have code to parse the EDID
correctly (given it has been read into a file as it is when OF does it).
Since OF is not setting up my monitor properly and I need something like
this, my idea was much simpler. I was just going to change the Radeon
panel_yres parameter into a USE_EDID flag that would be used to trigger a
parsing of the EDID info from the file put there by OF. All of this would
be done internal to the radeonfb.c driver.
But that would not be the more complete solution you are sugggesting, it
would not handle the hot-plug events, etc., different heads, etc.
So your solution sounds like a better overall way of integrating things
rather than the piecemeal way things are beig done now.
My 2 cents.
Kevin
> Given all the cruft about video modes & flat panels lately, what about
> adding some generic fbdev mode management (extending modedb) this way:
> All driver that know how to retreive DDC/EDID informations or the old
> mac mode sense pins, provide this to the modedb module.
>
> This module is responsible for using that info and command line infos
> to produce a sensible default display mode. It has a userland interface
> to make these infos easily available to candidate mode switchers (like
> MOL for example, but also a distribution XFree autoconfig tool).
>
> It also has an event interface for drivers that can autodetect hotplug
> and unplug of the video connector. Actually, it could be in a more
> central place in fbdev arch and also do heads management.
>
> In this case, drivers would register potential "heads" (connectors)
> indicating if they are independant or not (can only do mirroring), and
> if something is actually connected to them (most cards seem to be able
> to tell it).
>
> We can have things like mirror-only heads that can have a different
> mode timing, our current interface doesn't seem really nice for it.
> This is classical on some laptops where the LCD is at 60hz, but you
> can mirror with a better refresh rate.
>
> What do you think ?
>
> I beleive the first step is to add some kind of DDC/EDID parser to
> modedb that returns a matching mode entry and maybe merge the old
> mac-sensing codes into it (using a table mac-mode -> modedb mode).
>
>
> Ben.
|
