Next Previous Contents

1. Summarizing what has been discussed

By Brian Julin, Jan 28, 1998:

  1. If an IRQ is available (we haven't seen many SVGA cards that do more than _say_ they can activate IRQ), the kernel _could_ catch it. However, latency is high for a signal to get to user space, so the IRQs are of limited use. We would actually want the signal to arrive when _blanking_, not vretrace is active anyway, and for the signal to be issued even before that so the application gets it at or right before blanking starts.
  2. Some common uses for vretrace (page flipping) should be available as kernel-space driver functions to avoid this latency.
  3. If using the RTC, it has to be set up for one-shot mode and reset on every trigger, as well as calibrated with the hardware, the way the PC speaker driver does it, but fortunately at a much lower frequency :-). The periodic RTC freqs don't yeild good results because they are not flexible enough.
  4. Very few cards seem to allow you to read the CRTC address counter back out of the card. This being the case, the only way to know when blanking is asserted is to calibrate with the vsync pulse via polling the "retrace active" registers, and calculate the amount of time to offset the event from the mode parameters. Thus you have something like:
    
             (RTC IRQ)  -> Send Event
                           Set one-shot to 5ms
                           return
             (RTC IRQ)  -> Poll until vretrace bit active
                           unset vretrace bit latch
                           do some calibration calculations.
                           Set one-shot to 60ms + error term
                           return
    

  5. The kernel clock calibrator might benefit from using the "hretrace active" register once it has locked onto the right scanline if it does not drift too far. It still must check back occasionally and verify sync with the vretrace.
The new method of sharing the GC page could allow for some driver-libs to aid calibration from user space -- a field could be set in the shared page by the driver when the event is issued. The driver-lib could compare jiffies and pass back an average latency for the signal and context switch. Then the clock sync loop would be able to work that latency into the offset it applies to the vsync pulse. Thus only the kernel ever does active polling, and does so very efficiently we can hope.


Next Previous Contents