[PATCH 0/6] Move main() from DIX to DDXen
zt.tmzt at gmail.com
zt.tmzt at gmail.com
Mon Jan 17 08:23:21 PST 2011
On Jan 17, 2011 9:20 AM, "Jon TURNEY" <jon.turney at dronecode.org.uk> wrote:
> This is more in the nature of a RFC, but this is the least-bad approach I
> managed to come up with.
> Why do I want to do this? This set of changes lets me untie a few knots
> 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
> be built at the same time as those that do.
> * I'd like for a statically linked DDX to be able install another GLX
> such that it gets chosen in preference to swrast, and to solve that
> 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
> 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
> needed to create the lockfile successfully), but OsVendorInit() is too
> 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
> 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
I'm the developer working on the X server for Android, Androix (androix.org)
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.
tmzt on freenode
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg-devel