Re: EDID vs. fbmon & radeon

quoted

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.

If you look at my radeonfb work, you'll notice that I do pretty much like
XFree: that is I provide low level i2c routines to the kernel i2c layer,
and later one use these along with chip specific code (actually copied from
XFree) to retreive the EDID. It can't be all factored due to some HW gory
details though.

:-( I just want to make the drivers as simple as possible to create. 
 

What XFree does though is to parse the EDID and expose structures containing
the decoded timing infos so that the driver can actually pick individual
modes in there knowing which ones come from detailed timing blocks and
chich ones are calculated VESA modes. We could acheive the same by adding
some flags to the modedb we generate.

Make it so.....

P.S
	So I got swarmed with emails. I had some reading to do. BTW where 
is this new code. I like to commit to fbdev BK tree. 

P.S.S
	I did some work on your fbdev pm stuff. I will send another email 
about this.




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