> > As the author of Xgl and glitz I'd like to comment on a few things. > > >From the article: > > > Xgl was designed as a near term transition solution. The Xgl model > > was to transparently replace the drawing system of the existing > > X server with a compatible one based on using OpenGL as a device > > driver. Xgl maintained all of the existing X APIs as primary APIs. > > No new X APIs were offered and none were deprecated. > .. > > But Xgl was a near term, transition design, by delaying demand for > > Xgl the EXA bandaid removes much of the need for it. > > I've always designed Xgl to be a long term solution. I'd like if > whatever you or anyone else see as not long term with the design of Xgl > could be clarified.
I sent this comment to Jon before he published: "Xgl was never near term, maybe you thought it was but no-one else did, the sheer amount of work to get it to support all the extensions the current X server does would make it non-near term ..." I believe he is the only person involved who considered it near term, without realising quite how much work was needed... Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/