Umm, meant to also CC the list... Adding actual DGA2.0 support (currently we "support DGA2.O" because DGA2.0 servers run our code which uses DGA1.x calls.)w ill get us a target capable of using some advanced features (transparent BLT, offscreen Blt area in pixmap format) which will be useful for LibGAlloc/LibBuf/LibBlt. ---------- Forwarded message ---------- Date: Sat, 23 Jun 2001 18:44:39 -0400 (EDT) From: Brian S. Julin <[EMAIL PROTECTED]> To: Andreas Beck <[EMAIL PROTECTED]> Subject: display-dga On Fri, 22 Jun 2001, Andreas Beck wrote: > Same here. I think the internal DGA implementation is the problem. > It doesn't recognize DGA 1.1 which seemingly changed the protocol or > something. OK, well after looking things over, I think the internal implementation is a good idea -- it allows us to use a single .so for DGA 1.x and 2.x without worrying about symbols/linking and will give us flexibility to cope with glitches in individual minor release versions of DGA servers which are not coped with satisfactorily in the stock XFree libs. I think Marcus may have done it at first for thread safety, though. I think we should add DGA 2.0 to it, which will mean when it is disabled, if you compile with 2.0 support, the binary will fail to link with older xf86dga.so's, so we'll need a flag to compile only 1.x support. Now as for enabling DGA 2.0, right now I have 4.0.3 versions of the x libraries installed, which have a back compatibility layer to DGA 1.x Here are how the differences stack up -- if you have actual 3.3.x library sources installed maybe you could figure out the third column (I can download them as well, but figured I'd ask, as I'm about to abandon this for a day or so.) 2.x 1.1/2.x compat 1.x --------------------------------------------------------------------- XDGAQueryExtension == XF86DGAQueryExtension XDGAQueryVersion == XF86DGAQueryVersion -- XF86DGAGetVideoLL -- XF86DGADirectVideoLL -- XF86DGAGetViewPortSize XDGASetClientVersion -> XF86VidModeSetClientVersion XDGAOpenFramebuffer != XF86DGAGetVideo XDGACloseFramebuffer ?? XF86DirectVideo XDGAQueryModes -> XF86VidModeGetAllModeLines XDGASetMode -> XF86VidModeSwitchToMode XDGASetViewport != XF86DGASetViewPort XDGAInstallColormap != XF86DGAInstallColormap XDGASelectInput we use input-xwin XDGAFillRectangle !! XF86DGAFillRectangle XDGACopyArea !! XF86DGACopyArea XDGACopyTransparentArea -- XDGASync -> XSync XDGAChangePixmapMode -- XDGACreateColormap -> XCreateColormap XDGAKeyEventToXKeyEvent -- XF86DGAGetVidPage -- XF86DGASetVidPage -- XF86DGAQueryDirectVideo XDGAGetViewportStatus != XF86DGAViewPortChanged -- XF86DGAForkApp '==' means the DGA 1.x code just calls the DGA 2.x code '!=' means the prototypes differ '->' means a function from another library (Xlib, Xext, Xxf86VideoMode) is used '!!' means "rogue" extension functions as referred to in these newer headers, and the #define values they used are left undefined to keep from conflict. So the XFree folks do not consider these commands to be an official part of the DGA 1.x protocol. Other notes: any DGA1.x compatible function and the DGA1.x use XDGACheckExtension, which uses XextCheckExtension, while the DGA2.x-only function use XextSimpleCheckExtension with different parameters. The DGA 1.x code I have has handling for multiple screens, while the GGI internal implementation does not. Our internal XF86VMode either does not have some code in it for support of older versions of XF86VMode, or does not have code for the newer versions; this includes a different GetReq function. I wonder if calling XDGASetViewport with the value that the viewport is already set to will wait for retrace even though the value is identical -- if that is the case, we have a way to implement WaitRetrace in LibGGIMISC by doing that and polling on XDGAGetViewportStatus / XF86DGAViewPortChanged. -- Brian P.S. I have a patch now that adds -physz and -noinput to display-dga, though I haven't quite tested it yet thoroughly yet.
