So I've fleshed out most of a working solution for hotplugging and gpu switching but I've started wondering how to move ahead with upstreaming and finishing it off.
The quick high level overview is I introduced an impedance layer between the protocol types and a new set of driver types, the impedance layer translates the protocol types of Screen, GC, Drawable (Pixmap+Window), Picture to the driver types of DrvScreen, DrvGC, DrvPixmap and DrvPicture. Now above the impedance layer lies all the protocol processing code, and below the layer lies all the drawing code. The layer does all the window->pixmap translations including composite unwrapping. So all the drivers see are pixmaps + pCompositeClip inside the GC/Picture. The operations are transformed into a coordinate space of the pixmap being rendered to. So currently I've duplicated most of the fb, exa and lots of pieces of mi code into my drv subdir and replaces all the types and removed all the code. Now I have three strategies for dealing with this: a) disruptive - move all the code from above impedance layer to below impedance layer, stop shipping it above the impedance layer. Make the new API the only driver API we expose, fix problems like a mad bastard in the impedance layer (its not perfect yet). This saves us carrying two copies of mostly the same code. It does mean a bumpy cycle, and it will make it harder for drivers to build/run against older/newer servers. b) duplicate and rename: fb->drvfb, exa->drvexa, shadow->drvshadow, damage->drvdamage, mi->drv. Now we have duplicated stacks which drivers use depending on whether they support the new or old ABIs. The server can maintain both APIs but hotplug and features like that are only available to drivers through the new API. After a couple of cycles we deprecate and remove the old API and all the original code. The big disadvantage is we carry two sets of code for a lot of stuff and it isn't shared. c) try and share the code as much as possible: This relies on keeping the internals of the exposed structures quite similiar. We have to take every file that can be shared and template it to deal with both sets of types, above and below the impedance layer. We would probably have to generate a large tables of #defines to prefix all the function names with a new identifier and also rework the code where there are differences or cannot share. This could be something as leaving the current types and function names in place and using a large sed scripts to build new C files on the fly that we compile into new modules, or something more complex involving changing function names and types so the code gets built in one of the other modes. This is of course only one of the issues I face, but I would need to get some ideas on merging and keeping the tree in some ways stable. Dave. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel