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 <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
