patches on FC3 Re: [ANN] X11R6.8.2 Release Candidate 1 is out!

[Mike A. Harris]

Sergio Monteiro Basto wrote:
> +#define BuildDevelDRIDrivers YES

The Devel drivers are not part of the normal set of drivers built in 
X.Org, because they are in a state of development, and are either 
incomplete or insecure, or both, or have other known major issues of 
some sort.  Once these drivers are considered both stable as well as 
secure, they will probably be changed to be built by default in X.Org 
upstream however.

While we will not ship or support drivers that are known unstable or
insecure in Fedora Core, we definitely encourage developers and/or users
to compile the devel drivers and test them and report bugs to X.Org
bugzilla, as this will help greatly to stabilize them so they can be
included by default in future X.Org releases.

I don't believe Savage DRI works properly currently.


> 1 - 26 patches applied, some of than are marked has important, why they
> aren't applied on xorg cvs, yet ? ( if I got a problem will be more
> difficult trace it).

In general, like Kristian has mentioned, we want to get as many patches 
upstream into X.Org as possible.

One of our goals is to have as few patches in the Fedora Core xorg-x11 
spec file as possible, by having future patches merged directly into 
X.Org CVS head first, before we apply them to our rpms.  In some cases 
however, we need hotfixes right away, and may apply them prior to their 
inclusion in CVS head.  We definitely want to minimize that as much as 
possible however, as it is beneficial to both X.Org, and to us, to have 
all patches upstream, rather than having to cart them around for a long 
time.  Hopefully we will have gotten all of the relevant patches merged 
into X.Org prior to the next major release (X11R7?).


> 2- This one, is a old question but seems, to me, appropriated.
> xorg-x11-devel has included all xorg-x11-Mesa-devel and if I want
> compile Mesa from sources it is a big confusion, so for me should be
> split ed.

When X.Org is modularized completely, it may make sense to have Mesa as 
a separate set of RPM packages again, if it builds with DRI support 
outside of the X source tree now.  In the past, Mesa didn't build with 
DRI support, and required extra effort to build it DRI enabled outside 
of X packaging.  Once we no longer had to support software GL on 3.3.6 
servers, we stopped shipping Mesa separately in order to reduce the 
maintenance overhead of maintaining the heavily hacked up rpm packages. 
  Definitely not something we'd want to do again.  ;o)

If Mesa builds standalone now with DRI support though, or builds against 
the X.Org SDK or whatever, this would be something worth investigating. 
  I don't follow Mesa development that closely nowadays though, so I'm 
not quite sure if this is true or not, but I'm sure someone reading this 
can confirm/deny for me.

> but the worst is, GL includes are putted on /usr/include/GL
> instead /usr/X11R6/include/GL why ? if I compile xorg from cvs make
> install puts it on /usr/X11R6/include/GL why you change the location ? 

The OpenGL ABI on Linux officially specifies that libGL (or a symlink
to the libGL) must reside within /usr/lib, and the headers must be in 
/usr/lib/GL (or a symlink pointing to them).  In our OS, the GL libs in 
/usr/lib are actually symlinks pointing to the actual X.Org supplied
libGL, libGLU, which is OpenGL ABI compliant.

The headers also must be in /usr/include/GL for compliance, although
that can also be a symlink to elsewhere legally.  You can of course move 
the symlinks around if you wish, but rpm based upgrades will either 
break, or will overwrite whatever you put in there outside of rpm 
context, so I would highly discourage doing so.

The best place to put 3rd party libGL replacements and headers is in 
/usr/local/ or /opt/ or somewhere else, and properly pass the compiler 
the right flags to have it use the right includes/libs.

Hope this helps.
TTYL