X server 1.3 release status, plea for driver developer comments

[Andy Ritger]

Sorry I've not provided feedback sooner, Keith.  I'm still digesting
everything.

My biggest concern for the NVIDIA driver was the ability to provide
backwards compatible behavior when the driver advertises "fake" modes to
XF86VidMode/RandR that are really the bounding box of a TwinView/MergedFB
MetaMode.  It looks like that backwards compatible behavior should
be fine.  The NVIDIA driver will most likely give users the option of
either the old TwinView behavior (in which case the driver won't call
xf86RandR12Init()), or the RandR 1.2 behavior, in which case the old
TwinView behavior will be replaced with RandR 1.2 behavior.  That much
looks like it should be OK.

A few minor things I've noticed:

     - when a non-1.2 RandR driver is used, I see a SEGV when
       ProcRRSetScreenConfig() calls:

             if (!RRCrtcSet (pScrPriv->crtcs[c], NULL, 0, 0, RR_Rotate_0, 0, NULL))

       but RRCrtcSet() dereferences the passed-in NULL pointer 'mode' argument:

             size.width = mode->mode.width;

       I'm not sure how much of RRCrtcSet() should be skipped if the mode is NULL.

     - in rrmode.c, the list is stored globally, rather than per X screen
       (i.e., 'modes' and 'num_modes' are static global variables);
       shouldn't these be stored instead in, say, the rrScrPrivRec?

     - in xf86CrtcSetMode(), it would make sense for the call to
       output->funcs->mode_set() to be wrapped with a more generic
       "pre_mode_set/post_mode_set", rather than crtc->funcs->dpms(Off/On)
       calls.

In terms of the actual driver API for RandR 1.2, I don't have much to
say, yet.  It might be good to document the API in the XFree86 DESIGN
document (xserver/hw/xfree86/doc/DESIGN.sgml), for use as a reference
for others.

Thanks,
- Andy


On Tue, 20 Feb 2007, Keith Packard wrote:

> I spent a bit of time over the long weekend cleaning up the X server
> tree in preparation for the 1.3 release. Here's the current status:
>
> The proposed patches have been merged; one new one for Xephyr appeared
> after I merged the others; I'll look at that and pull it across shortly.
>
> The new mode setting API is all pushed over to the X server and pulled
> out of the Intel driver. For now, building the Intel driver is a bit of
> a pain as it requires current X server sources, even if you are building
> against an older server. When we release tarballs for the driver, the
> needed sources will be automatically included so this won't be a problem
> there.
>
> EXA damage track has been merged over, along with a few new fixes.
>
> The biggest question remaining in my mind is whether the new mode
> setting API is ready to be stabilized. Aaron Platner and Andy Ritger
> have both expressed a desire for some minor changes; I haven't seen
> anything from them since XDC though. Dave Airlie was also interested in
> similar changes, but he hasn't sent anything either. Tilman Saurerbeck
> has found more code in the intel driver that should be moved out to the
> server common area; I'll be working on that tomorrow if I get some time.
>
> So, I think we're nearly ready to go, but I want to ask driver
> developers to take a few minutes to report whether they've looked hard
> enough at the new mode setting API to tell whether it will work with
> their chips. Changing it after 1.3 will be harder than before, so let's
> work to make those changes unnecessary, or at least easier to make in a
> compatible fashion. Of course, the server APIs should be flexible enough
> that we can replace the mode setting code yet again if this stuff is
> completely messed up, but I'd certainly prefer that we not have to do
> that again this year.
>
> And, of course, if you have additional comments or questions about this
> release, please make them known sooner rather than later; we can't fix
> what we don't know is broken.
>
> -- 
> keith.packard at intel.com
>