Help fixing csync output with video-ati

[Fernando Carrijo]

Sorry, I really don't know the solution of your problem. I am myself
still fighting to understand most of this code you are also striving
to get. Nevertheless, I have a few unpretentious comments about what
you said. Take them with a pile of salt, for their purpose is more
of an exercise than anything else.

Arvid Brodin <arvidb at kth.se> wrote:
> I downloaded the xorg-server-1.6.5 package, searched for RRCreateMode()
> there, and found ProcXRRCreateMode() which I *guess* is the handler for
> this call.
> 
> Nothing very exciting seems to happen in that code path, in regards to
> the modeFlags. The mode is just stored away (as could be expected ;).
> 
> The code path for xrandr --output ... --mode ... was more interesting
> though. I believe the call stack looks something like this:
> 
> xrandr
> ======
> apply()
> crtc_apply()
> 
> libXrandr
> =========
> XRRSetCrtcConfig()
> 
> xserver
> =======
> ProcRRSetCrtcConfig() ??

Have a look at the bottom of xserver/randr/rrdispatch.c. All requests
introduced the RandR extension, in all its versions, are serviced by a
dispatch vector called ProcRandrVector. It happens in a similar vein,
as far as I can tell, with the core requests and the requests defined
by all other extensions.

> RRCrtcSet()
> (*pScrPriv->rrCrtcSet)() == xf86RandR12CrtcSet() ??

Someone more knowledgeable than me shall tell for sure, but I believe
most of the functions dereferenced through pScrPriv-> are supposed to
be provided by the driver which drives the screen. So, unless there's
a default implementation for it, you should consult not that one, but
the one which comes along your driver.

This snipped of code, and in particular the comment which precedes it,
taken from xserver/randr/mirandr.c strongly suggest the plausability
of what I'm saying. I may be totally wrong about it, though.

  /*
   * Any hardware that can actually change anything will need something
   * different here
   */
  Bool
  miRRCrtcSet (ScreenPtr	pScreen,
               RRCrtcPtr  crtc,
               RRModePtr  mode,
               int        x,
               int        y,
               Rotation   rotation,
               int        numOutput,
               RROutputPtr *outputs)
  {
      return TRUE;
  }

You may want to take a look at miRandrInit() and see it for yourself.

> xf86RandRModeConvert(pScrn, randr_mode, &mode);
> xf86SetModeCrtc(mode, scrn->adjustFlags); (DisplayModePtr mode, int
> adjustFlags)
> 	mode->Crtc<X> = mode-><X>; (not Flags)
> xf86RandR12CrtcNotify()
> RRCrtcNotify(randr_crtc, randr_mode, x, y, ...)
> 	crtc->mode = mode;
> RRCrtcChanged(crtc, TRUE)
> 
> "??" meaning more guesswork than usual was required. :)
> 
> The bad part is, I still cannot find where the "magic" happens.
> RRCrtcNotify() sets crtc->mode, and RRCrtcChanged() sets
> pScrPriv->changed and pScrPriv->layoutChanged to TRUE, and that's it, as
> far as I can see. Either I've missed some call somewhere, or the actual
> setting happens asynchronously. I've also not been able to find any
> filtering of the CSYNC flag anywhere.
> 
> Ideas?
> 
> BTW, does composite sync work on other architectures, like Intel?

Someone more experienced will know. They usually pop up on Mondays. :)

> 
> -- 
> Arvid Brodin