On 02/15/2012 05:15 PM, Matt Turner wrote:
On Wed, Feb 15, 2012 at 7:52 AM, tf (mobile)<tfo...@sci.utah.edu> wrote:
Even if the system supports tls, the x server may not have been built with it.
As i recall, there is an issue with mismatching tls between x and drivers...
Can a non-tls server load a tls driver?
I don't think mismatching TLS/non-TLS Mesa and X server works, but I
don't think that's a combination anyone cares to support (or is
possible to support?).
Depends on the mismatch. If X is TLS and Mesa isn't, no problem. If
Mesa is TLS and X isn't, drivers won't load. There was some vague
interest on getting that to work a while back, but nobody wanted to do
the work and it wasn't considered very important.
Anyway, if there's an issue there, this check must be more complicated -- it can't be just,
"does the system support this", it would instead need to be "can the system support
this and is it enabled in the x server."
The X server isn't required to compile Mesa, so it doesn't make sense
to try to check if the X server supports TLS.
This is a silly argument: we can very easily detect the cases in which
Mesa is built to be used as an X driver or not.
> I think the idea is, if
the system supports TLS, let's default to enabled for both Mesa and
the X server, and if you do something else and it breaks then you get
to keep the pieces.
I am concerned about systems which --disable-tls when building X, and
omit such a flag when building Mesa in a relevant configuration. I
think we should have an AC_MSG_ERROR for that case.
-tom
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
