Re: EDID vs. fbmon & radeon

I'm working on radeonfb to implement full DDC2 support among other,
however, I'm having a problem with the way you currently put the EDID
code in fbmon.c

I have been watching. Really cool stuff. 
 

Right now, most of the actual EDID parsing is done within fbmon with
static functions, all I can do from the "outside" is to either use
parse_edid which will get me the first detailed timing block or
build a modedb, which will cause me to lose the information of what
comes from the detailed block, and what is a strandard VESA timing.

For proper flat panel setup, I need to actually know what is a detailed
timing block and iterate over those specifically to figure out the
proper panel informations that I'll need later on to configure the
RMX (scaler engine), among others. For now, I'll be using parse_edid()
but I would prefer iterating them all 4 so I can pick the largest one,
in case the panel does HW scaling and expose that some way...

We could either export low-level parsing routines from fbmon.c so I
can do my own parsing in special cases like this one, we could just
extend the modedb created with a few flags indicating for each mode
where it comes from (detailed block, vesa block), or we could output
some different EDID-specific data structure containing the parsed
EDID in various arrays like XFree does....

What do you think ?

Hm. The most important goal I think should be that as much as possible 
code sharing goes on. The way XFree86 handles it is that th edrivers only 
have to deal with 2 functions for writing the i2c register. Everything 
else is handled by a upper layer. I like to see fbdev have the same thing.

(BTW. What about those fb_client patches ? Any chance we get that in
Linus tree soon ? )

Yes. I have viewed the code and I like to go over some ideas with you on 
it. I will post my comments tomorrow. 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf