From: Sven L. <lu...@dp...> - 2003-03-06 11:41:28
|
On Thu, Mar 06, 2003 at 06:51:58PM +0800, Antonino Daplas wrote: > On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote: > > On Thu, 2003-03-06 at 18:31, Sven Luther wrote: > > > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote: > > > > Yes, there is. Using the "stale" pixelclock, htotal and vtotal, > > > > calculate hsync and vsync. Compare this with your monitor's limit -- if > > > > any fall outside, the entire mode, pixelclock and all is not valid. > > > > > > > > (see fb_get_mode() and fb_validate_mode() in fbmon.c) > > > > > > > > And if you use very narrow vsync and hsync ranges, then the "stale" > > > > pixelclock will always most certainly be invalid. > > > > > > BTW, do we have an easy way of knowing if it is an LCD or analog monitor > > > which is attached to the card (or even a TV) ? I think the radeonfb > > > knows how to do this, not sure though. > > > > > > > There's an EDID parser in fbmon.c. I think it will work only for the > > PPC. This is currently used by rivafb and radeonfb. For the rest, either Mmm, is it because the EDID parser uses the EDID information pased by the OF ? > > we implement DDC or just have something similar to XF86Config's > > HorizSync and VertRefresh. We can load this either as a kernel/module > > option or passed via ioctl/sysfs. Most monitors today have DDC support, so i guess best would be to use it, and fall back to a command line option if DDC is not supported. > > I'm already doing this with the i810fb (as boot/module option), which > > greatly simplified mode switching. > > Oops, totally missed your question :-) But yes, I think the EDID block > contains information about the monitor type, not sure thogh. X finds : Digital Display Input So, i guess this is it. Friendly, Sven Luther |