[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
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 (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.

--
Timothy Meade
tmzt on freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110117/ed92676d/attachment-0001.htm>


More information about the xorg-devel mailing list