On Sat, 27 Nov 1999, Andreas Beck wrote:
> > > before. Actually I have todays CVS from GGI. Testing their library. I
> > > noticed the you can lower/raise the ramdac clock. You can also control the
> > > clock the same way from userspace. Geert should we have such features for
> > > fbdev? Emmanuel are you still around? How about incorporating it into the
>
> > I'm sorry, but I don't understand this. What do you mean by `lower/raise the
> > ramdac clock'? Isn't the ramdac clock always the same as the pixel clock?
>
> I think he is talking about kgicon's ability to automatically negotiate a
> timing using the "monitor driver" component of a kgi driver.
Not quite. What I was asking about was the clock code for cx5520.c for the
cyrix KGIcon driver. I noticed you have in kgim_clock_check_mode several
options dealing with what looks like you raising and lowering the
clocks. Most of the KGIcon code is pretty straight forward except the
clock(PLL) code. I will have questions on this code. The faster I learn it
the faster I can intergrate all your drivers into teh main stream kernel
:)
> Using this feature, you can upload a monitor configuration profile into the
> monitor driver from userspace, and the system will automatically select
> optimum refresh modes from then on based on the various constraints that
> chipset, ramdac, pixelclock and the monitor set up.
> The system also allows to set explicit timings for given modes, which may be
> desireable to match the mode to those set by other OSes or XFree to avoid
> having to set up multiple geometry slots for the same mode in the monitor.
Actually fbdev is starting to have such features for the monitor. If you
look at 2.3.29 I added a very early incomplete framework for monitor
handling. The file is linux/drivers/video/fbmon.c which explains my
ideas. The purpose is prevent things like setting modes which the video
cards can handle but the monitor can't. Also if you have a monitor switch
box you can share the monitor defination with all the video cards you have
in a box. In fact I should get a switch box. This way I can change back
and forth between video cards. The exact framework will need to be thought
out in great detail.
> Regarding your other question:
>
> > Isn't the ramdac clock always the same as the pixel clock?
>
> Not quite, depending on the exact definition of pixel clock.
> Using doubling-capabilities of the chipset, it may well be, that the
> programmed clock of the clock systhesizer is higher than what the ramdac
> gets. However it might as well be, that the ramdac is still driven at the
> high frequency, just getting allways the same pixel twice. Depends on
> implementation.
Oops. I made the same mistake thinking they where the same. I believe
fbdev has that feature supported with FB_VMODE_DOUBLE. Perhaps we still
can you fb_var_screeninfo.pixclock and this flag to properly set the
ramdac clock for a particular chipset. I see a few drivers handle this
properly like matroxfb.
-----==-
----==-- _
---==---(_)__ __ ____ __ James Simmons
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\ fbcon/gfx developer
The choice of a GNU generation
