Index: [thread] [date] [subject] [author]
  From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com, James Simmons <jsimmons@edgeglobal.com>
  Date: Sat, 27 Nov 1999 11:52:24 +0100

Re: [linux-fbdev] Cyrix Cx5530

> > 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.

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.

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.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =


Index: [thread] [date] [subject] [author]