On Jan 17, 2011 9:20 AM, "Jon TURNEY" <<a href="mailto:jon.turney@dronecode.org.uk">jon.turney@dronecode.org.uk</a>> wrote: > > This is more in the nature of a RFC, but this is the least-bad approach I have > managed to come up with. > > Why do I want to do this? This set of changes lets me untie a few knots that > XWin finds itself in at the moment: > > * libdix comes in 2 different flavours, depending on if it's > built with ROOTLESS defined or not, so DDXs which don't support ROOTLESS can't > be built at the same time as those that do. > > * I'd like for a statically linked DDX to be able install another GLX provider > such that it gets chosen in preference to swrast, and to solve that problem > without creating another instance of the problem above. > > * The first point at which the DDX gets to execute is either > ddxProcessArgument() (if arguments were supplied), otherwise OsVendorInit(). > This uncertainly makes it unneccessarily painful to implement command line > options with a default depending on the environment. > (There's also a specific problem in that I'd like to have XWin default to > -nolock if the filesystem for /tmp is FAT (as it doesn't support the semantics > needed to create the lockfile successfully), but OsVendorInit() is too late to > check this, as by that time, the lockfile has been created.) > > Jon TURNEY (6): > Move main() from dix to ddx > Replace DDXBEFORERESET with a more general way of doing DDX-specific > hooks > Add a DDX specific GLX provider push hook > Add a DDX specific hook into miPaintWindow for DDXen which support > the rootless extension > Make building XWin with WINDOWSWM and ROOTLESS mandatory > Revert libmain.a > Hi Jon, I'm the developer working on the X server for Android, Androix (<a href="http://androix.org">androix.org</a>) and your work on XQuartz was indispensible for that, so thanks. I have a similar problem, though it doesn't effect the present Java JNI (as either main() or dix_main() will work), it will be an issue with native applications in 2.3. I am all for this, as I don't have arguments or config files to parse but do need to negotiate some things or retreive settings from the Android application having a custom main() is neccessary and being able to call it what I want (for the native app version) is as well. I can't comment on GLX (or a future GLXES) yet because I haven't begun implementing that in my server. -- Timothy Meade tmzt on freenode