XFree86 4.5.0 release schedule

2005-01-08 Thread David Dawes 
The schedule for the next XFree86 release -- 4.5.0 is as follows:

   26 January 2005feature freeze
   late February 2005 code freeze
   early-mid March 2005   release

The feature freeze date is the date by which non-bug-fix submissions
need to be received in order to be considered for inclusion in the 4.5.0
release.  The code freeze date is the point at which only seriaous bug
fixes and documentation updates are accepted.

Submissions may be made through the XFree86 bugzilla at bugs.xfree86.org
or via email to [EMAIL PROTECTED]  It is also a good idea to send a
note here regarding new submissions or for previous submissions that
have not been committed yet.  Submissions should be integrated/tested
against the most recent XFree86 snapshot or the current CVS trunk, and
submitted as patches against such.  XFree86 snapshots can be found at
.

The actual code freeze and release dates will be nailed down as they get
closer.

David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-10 Thread Matthias Scheler 
On Sat, Jan 08, 2005 at 07:37:29PM -0500, David Dawes wrote:
> The schedule for the next XFree86 release -- 4.5.0 is as follows:
> 
>26 January 2005feature freeze
>late February 2005 code freeze
>early-mid March 2005   release

Is a list of changes for this release already available somewhere?

Kind regards

-- 
Matthias Scheler  http://scheler.de/~matthias/
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-10 Thread David Dawes 
On Mon, Jan 10, 2005 at 08:43:18AM +, Matthias Scheler wrote:
>On Sat, Jan 08, 2005 at 07:37:29PM -0500, David Dawes wrote:
>> The schedule for the next XFree86 release -- 4.5.0 is as follows:
>> 
>>26 January 2005feature freeze
>>late February 2005 code freeze
>>early-mid March 2005   release
>
>Is a list of changes for this release already available somewhere?

Most changes are listed in the changelog file in the source tree.  There
are some exceptions: for example, the latest Mesa/DRI updates, which
should probably be added to the changelog.

I'll be putting up a first draft of the 4.5.0 docs soon, and submissions for
release notes content are welcome.

David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-11 Thread Alan Hourihane 
On Mon, Jan 10, 2005 at 11:00:22PM -0500, David Dawes wrote:
> On Mon, Jan 10, 2005 at 08:43:18AM +, Matthias Scheler wrote:
> >On Sat, Jan 08, 2005 at 07:37:29PM -0500, David Dawes wrote:
> >> The schedule for the next XFree86 release -- 4.5.0 is as follows:
> >> 
> >>26 January 2005feature freeze
> >>late February 2005 code freeze
> >>early-mid March 2005   release
> >
> >Is a list of changes for this release already available somewhere?
> 
> Most changes are listed in the changelog file in the source tree.  There
> are some exceptions: for example, the latest Mesa/DRI updates, which
> should probably be added to the changelog.
 
Sorry, I thought I'd done that. I'll fix it now.

Alan.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-11 Thread Marc Aurele La France 
On Sat, 8 Jan 2005, David Dawes wrote:
The schedule for the next XFree86 release -- 4.5.0 is as follows:

  26 January 2005feature freeze
  late February 2005 code freeze
  early-mid March 2005   release

The feature freeze date is the date by which non-bug-fix submissions
need to be received in order to be considered for inclusion in the 4.5.0
release.  The code freeze date is the point at which only seriaous bug
fixes and documentation updates are accepted.

Submissions may be made through the XFree86 bugzilla at bugs.xfree86.org
or via email to [EMAIL PROTECTED]  It is also a good idea to send a
note here regarding new submissions or for previous submissions that
have not been committed yet.  Submissions should be integrated/tested
against the most recent XFree86 snapshot or the current CVS trunk, and
submitted as patches against such.  XFree86 snapshots can be found at
.

The actual code freeze and release dates will be nailed down as they get
closer.
Should an attempt be made to resurrect DMX before 4.5?
Marc.
+--+---+
|  Marc Aurele La France   |  work:   1-780-492-9310   |
|  Computing and Network Services  |  fax:1-780-492-1729   |
|  352 General Services Building   |  email:  [EMAIL PROTECTED]  |
|  University of Alberta   +---+
|  Edmonton, Alberta   |   |
|  T6G 2H1 | Standard disclaimers apply|
|  CANADA  |   |
+--+---+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-11 Thread David Dawes 
On Tue, Jan 11, 2005 at 08:31:54AM -0700, Marc Aurele La France wrote:
>On Sat, 8 Jan 2005, David Dawes wrote:
>
>>The schedule for the next XFree86 release -- 4.5.0 is as follows:
>
>>  26 January 2005feature freeze
>>  late February 2005 code freeze
>>  early-mid March 2005   release
>
>>The feature freeze date is the date by which non-bug-fix submissions
>>need to be received in order to be considered for inclusion in the 4.5.0
>>release.  The code freeze date is the point at which only seriaous bug
>>fixes and documentation updates are accepted.
>
>>Submissions may be made through the XFree86 bugzilla at bugs.xfree86.org
>>or via email to [EMAIL PROTECTED]  It is also a good idea to send a
>>note here regarding new submissions or for previous submissions that
>>have not been committed yet.  Submissions should be integrated/tested
>>against the most recent XFree86 snapshot or the current CVS trunk, and
>>submitted as patches against such.  XFree86 snapshots can be found at
>>.
>
>>The actual code freeze and release dates will be nailed down as they get
>>closer.
>
>Should an attempt be made to resurrect DMX before 4.5?

How seriously broken is it?

David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-11 Thread Kevin E Martin 
On Tue, Jan 11, 2005 at 12:41:15PM -0500, David Dawes wrote:
> On Tue, Jan 11, 2005 at 08:31:54AM -0700, Marc Aurele La France wrote:
> >On Sat, 8 Jan 2005, David Dawes wrote:
> >
> >>The schedule for the next XFree86 release -- 4.5.0 is as follows:
> >
> >>  26 January 2005feature freeze
> >>  late February 2005 code freeze
> >>  early-mid March 2005   release
> >
> >>The feature freeze date is the date by which non-bug-fix submissions
> >>need to be received in order to be considered for inclusion in the 4.5.0
> >>release.  The code freeze date is the point at which only seriaous bug
> >>fixes and documentation updates are accepted.
> >
> >>Submissions may be made through the XFree86 bugzilla at bugs.xfree86.org
> >>or via email to [EMAIL PROTECTED]  It is also a good idea to send a
> >>note here regarding new submissions or for previous submissions that
> >>have not been committed yet.  Submissions should be integrated/tested
> >>against the most recent XFree86 snapshot or the current CVS trunk, and
> >>submitted as patches against such.  XFree86 snapshots can be found at
> >>.
> >
> >>The actual code freeze and release dates will be nailed down as they get
> >>closer.
> >
> >Should an attempt be made to resurrect DMX before 4.5?
> 
> How seriously broken is it?

Here's an explanation of the issue with a proposed fix to maintain
backward compatibility:

http://sourceforge.net/mailarchive/message.php?msg_id=10290987

I've tested my patch to make sure that it works fine on Linux.  I don't
have an SGI box to verify that it still works fine on their systems.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-11 Thread Marc Aurele La France 
On Tue, 11 Jan 2005, Kevin E Martin wrote:
On Tue, Jan 11, 2005 at 12:41:15PM -0500, David Dawes wrote:
On Tue, Jan 11, 2005 at 08:31:54AM -0700, Marc Aurele La France wrote:
On Sat, 8 Jan 2005, David Dawes wrote:

The schedule for the next XFree86 release -- 4.5.0 is as follows:

 26 January 2005feature freeze
 late February 2005 code freeze
 early-mid March 2005   release

The feature freeze date is the date by which non-bug-fix submissions
need to be received in order to be considered for inclusion in the 4.5.0
release.  The code freeze date is the point at which only seriaous bug
fixes and documentation updates are accepted.

Submissions may be made through the XFree86 bugzilla at bugs.xfree86.org
or via email to [EMAIL PROTECTED]  It is also a good idea to send a
note here regarding new submissions or for previous submissions that
have not been committed yet.  Submissions should be integrated/tested
against the most recent XFree86 snapshot or the current CVS trunk, and
submitted as patches against such.  XFree86 snapshots can be found at
.

The actual code freeze and release dates will be nailed down as they get
closer.

Should an attempt be made to resurrect DMX before 4.5?

How seriously broken is it?

Here's an explanation of the issue with a proposed fix to maintain
backward compatibility:

   http://sourceforge.net/mailarchive/message.php?msg_id=10290987

I've tested my patch to make sure that it works fine on Linux.  I don't
have an SGI box to verify that it still works fine on their systems.
Well, if I were you, I'd commit something like that ASAP.  I can deal with 
the build issues, test case or no test case.  The point being that no one 
will fix it if it doesn't build.

Longer term though, we need to look at glxProxy being more of an #ifdef'ed 
derivative of GLX.

Marc.
+--+---+
|  Marc Aurele La France   |  work:   1-780-492-9310   |
|  Computing and Network Services  |  fax:1-780-492-1729   |
|  352 General Services Building   |  email:  [EMAIL PROTECTED]  |
|  University of Alberta   +---+
|  Edmonton, Alberta   |   |
|  T6G 2H1 | Standard disclaimers apply|
|  CANADA  |   |
+--+---+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-11 Thread Marc Aurele La France 
On Tue, 11 Jan 2005, Marc Aurele La France wrote:
On Tue, 11 Jan 2005, Kevin E Martin wrote:
On Tue, Jan 11, 2005 at 12:41:15PM -0500, David Dawes wrote:
On Tue, Jan 11, 2005 at 08:31:54AM -0700, Marc Aurele La France wrote:
On Sat, 8 Jan 2005, David Dawes wrote:
The schedule for the next XFree86 release -- 4.5.0 is as follows:

 26 January 2005feature freeze
 late February 2005 code freeze
 early-mid March 2005   release

The feature freeze date is the date by which non-bug-fix submissions
need to be received in order to be considered for inclusion in the 4.5.0
release.  The code freeze date is the point at which only seriaous bug
fixes and documentation updates are accepted.

Submissions may be made through the XFree86 bugzilla at bugs.xfree86.org
or via email to [EMAIL PROTECTED]  It is also a good idea to send a
note here regarding new submissions or for previous submissions that
have not been committed yet.  Submissions should be integrated/tested
against the most recent XFree86 snapshot or the current CVS trunk, and
submitted as patches against such.  XFree86 snapshots can be found at
.

The actual code freeze and release dates will be nailed down as they get
closer.

Should an attempt be made to resurrect DMX before 4.5?

How seriously broken is it?

Here's an explanation of the issue with a proposed fix to maintain
backward compatibility:

   http://sourceforge.net/mailarchive/message.php?msg_id=10290987

I've tested my patch to make sure that it works fine on Linux.  I don't
have an SGI box to verify that it still works fine on their systems.

Well, if I were you, I'd commit something like that ASAP.  I can deal with 
the build issues, test case or no test case.  The point being that no one 
will fix it if it doesn't build.

Longer term though, we need to look at glxProxy being more of an #ifdef'ed 
derivative of GLX.
Come to think of it, I'll be even blunter.  If DMX breaks every time GLX is 
resync'ed, then there's no point in keeping DMX.  This whether we're talking 
about XFree86's repository, or X.Org's.

So, I'd strongly advise you, Kevin, to talk to the GLX people in getting 
glxProxy done properly.

Marc.
+--+---+
|  Marc Aurele La France   |  work:   1-780-492-9310   |
|  Computing and Network Services  |  fax:1-780-492-1729   |
|  352 General Services Building   |  email:  [EMAIL PROTECTED]  |
|  University of Alberta   +---+
|  Edmonton, Alberta   |   |
|  T6G 2H1 | Standard disclaimers apply|
|  CANADA  |   |
+--+---+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-11 Thread Kevin E Martin 
On Tue, Jan 11, 2005 at 02:15:58PM -0700, Marc Aurele La France wrote:
> On Tue, 11 Jan 2005, Marc Aurele La France wrote:
> >On Tue, 11 Jan 2005, Kevin E Martin wrote:
> >>Here's an explanation of the issue with a proposed fix to maintain
> >>backward compatibility:
> 
> >>   http://sourceforge.net/mailarchive/message.php?msg_id=10290987
> 
> >>I've tested my patch to make sure that it works fine on Linux.  I don't
> >>have an SGI box to verify that it still works fine on their systems.
> 
> >Well, if I were you, I'd commit something like that ASAP.  I can deal with 
> >the build issues, test case or no test case.  The point being that no one 
> >will fix it if it doesn't build.
> 
> >Longer term though, we need to look at glxProxy being more of an #ifdef'ed 
> >derivative of GLX.
> 
> Come to think of it, I'll be even blunter.  If DMX breaks every time GLX is 
> resync'ed, then there's no point in keeping DMX.

glxProxy was developed by SGI is almost 100% independent from GLX as
used in the rest of the X server -- the only shared code is from some
header files.  One of those headers was changed but not properly
#ifdef'd by SGI to maintain backward compatibility with previous XFree86
releases.  The patch that I suggested fixes the backward compatibility
issue.  This is all explained in the thread that I referenced in my
previous message.

Unfortunately, I just discovered that there is a much more significant
issue: you've made changes to glxProxy on 4 Aug 2004 that broke the
build.  I've attached a patch to make it build again.  However, I cannot
verify the correctness of the changes you've made, since glxProxy is not
my code.  As I mentioned above, the code was donated by SGI.  I would
strongly suggest reverting the changes you've made until you can verify
with SGI that your changes are correct.

If you do revert the changes back to the way they were originally
checked in and then apply the patch from my message to the dri-devel
list (see URL above), then glxProxy should build and work properly, and
it should also be backward compatible with previous XFree86 releases.
Index: programs/Xserver/hw/dmx/dmx_glxvisuals.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/dmx/dmx_glxvisuals.c,v
retrieving revision 1.1
diff -u -r1.1 dmx_glxvisuals.c
--- programs/Xserver/hw/dmx/dmx_glxvisuals.c30 Jun 2004 20:21:38 -  
1.1
+++ programs/Xserver/hw/dmx/dmx_glxvisuals.c12 Jan 2005 00:13:53 -
@@ -147,12 +147,14 @@
int value = *p++;
 
switch (property) {
+#if 0
  case GLX_SAMPLES_SGIS:
config->multiSampleSize = value;
break;
  case GLX_SAMPLE_BUFFERS_SGIS:
config->nMultiSampleBuffers = value;
break;
+#endif
 
  case GLX_TRANSPARENT_TYPE_EXT:
config->transparentPixel = value;
@@ -177,10 +179,12 @@
config->visualRating = value;
break;
 
+#if 0
  /* visualSelectGroup is an internal used property */
  case GLX_VISUAL_SELECT_GROUP_SGIX:
config->visualSelectGroup = value;
break;
+#endif
 
  default :
/* Ignore properties we don't recognize */
@@ -591,9 +595,11 @@
  cfg->transparentBlue = fbcfg->transparentBlue;
  cfg->transparentAlpha = fbcfg->transparentAlpha;
  cfg->transparentIndex = fbcfg->transparentIndex;
+#if 0
  cfg->multiSampleSize = fbcfg->multiSampleSize;
  cfg->nMultiSampleBuffers = fbcfg->nMultiSampleBuffers;
  cfg->visualSelectGroup = fbcfg->visualSelectGroup;
+#endif
}
 }
 
Index: programs/Xserver/hw/dmx/glxProxy/g_renderswap.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/dmx/glxProxy/g_renderswap.c,v
retrieving revision 1.2
diff -u -r1.2 g_renderswap.c
--- programs/Xserver/hw/dmx/glxProxy/g_renderswap.c 4 Aug 2004 16:33:34 
-   1.2
+++ programs/Xserver/hw/dmx/glxProxy/g_renderswap.c 12 Jan 2005 00:13:53 
-
@@ -63,6 +63,7 @@
 
 void __glXDispSwap_Color3dv(GLbyte *pc)
 {
+   __GLX_DECLARE_SWAP_VARIABLES;
__GLX_DECLARE_SWAP_ARRAY_VARIABLES;
 
 #ifdef __GLX_ALIGN64
@@ -76,6 +77,7 @@
 
 void __glXDispSwap_Color3fv(GLbyte *pc)
 {
+   __GLX_DECLARE_SWAP_VARIABLES;
__GLX_DECLARE_SWAP_ARRAY_VARIABLES;
 
__GLX_SWAP_FLOAT_ARRAY(pc + 0, 3);
@@ -83,6 +85,7 @@
 
 void __glXDispSwap_Color3iv(GLbyte *pc)
 {
+   __GLX_DECLARE_SWAP_VARIABLES;
__GLX_DECLARE_SWAP_ARRAY_VARIABLES;
 
__GLX_SWAP_INT_ARRAY(pc + 0, 3);
@@ -90,6 +93,7 @@
 
 void __glXDispSwap_Color3sv(GLbyte *pc)
 {
+   __GLX_DECLARE_SWAP_VARIABLES;
__GLX_DECLARE_SWAP_ARRAY_VARIABLES;
 
__GLX_SWAP_SHORT_ARRAY(pc + 0, 3);
@@ -102,6 +106,7 @@
 
 void __glXDispSwap_Color3uiv(GLbyte *pc)
 {
+   __GLX_DECLARE_SWAP_VARIABL

Re: XFree86 4.5.0 release schedule

2005-01-12 Thread Marc Aurele La France 
On Tue, 11 Jan 2005, Kevin E Martin wrote:
On Tue, Jan 11, 2005 at 02:15:58PM -0700, Marc Aurele La France wrote:
On Tue, 11 Jan 2005, Marc Aurele La France wrote:
On Tue, 11 Jan 2005, Kevin E Martin wrote:
Here's an explanation of the issue with a proposed fix to maintain
backward compatibility:

  http://sourceforge.net/mailarchive/message.php?msg_id=10290987

I've tested my patch to make sure that it works fine on Linux.  I don't
have an SGI box to verify that it still works fine on their systems.

Well, if I were you, I'd commit something like that ASAP.  I can deal with
the build issues, test case or no test case.  The point being that no one
will fix it if it doesn't build.

Longer term though, we need to look at glxProxy being more of an #ifdef'ed
derivative of GLX.

Come to think of it, I'll be even blunter.  If DMX breaks every time GLX is
resync'ed, then there's no point in keeping DMX.

glxProxy was developed by SGI is almost 100% independent from GLX as
used in the rest of the X server -- the only shared code is from some
header files.  One of those headers was changed but not properly
#ifdef'd by SGI to maintain backward compatibility with previous XFree86
releases.  The patch that I suggested fixes the backward compatibility
issue.  This is all explained in the thread that I referenced in my
previous message.

Unfortunately, I just discovered that there is a much more significant
issue: you've made changes to glxProxy on 4 Aug 2004 that broke the
build.  I've attached a patch to make it build again.  However, I cannot
verify the correctness of the changes you've made, since glxProxy is not
my code.  As I mentioned above, the code was donated by SGI.  I would
strongly suggest reverting the changes you've made until you can verify
with SGI that your changes are correct.

If you do revert the changes back to the way they were originally
checked in and then apply the patch from my message to the dri-devel
list (see URL above), then glxProxy should build and work properly, and
it should also be backward compatible with previous XFree86 releases.
SGI's own compiler could not build what was originally committed for 
glxProxy, and GCC was also quite noisy about it.  Were this not so, I 
probably would not even have noticed that there a much much larger issue 
here.

As I reported back in August, the GLX protocol understood by glxProxy is 
significantly different from, and in many respects incompatible with, any 
native GLX implementation we've ever provided.  In effect, we are being asked 
to harbour and maintain a transport for a GLX implementation whose end-points 
are not within our purview to support.  If you care to examine glxProxy more 
closely, you will see that it is based on a separate, likely SGI-internal, 
GLX snapshot.  I wouldn't mind so much if Xdmx were more lbxproxy-like, but 
that's not the case here.  Fortunately, GLX is the only extension Xdmx 
provides its own framework for.  It would also seem your glxProxy testing 
only relied on a common subset of GLX.

I also stated back then that my changes, in addition to fixing build issues, 
also represented a first, necessarily incomplete, swipe at re-aligning 
glxProxy's GLX implementation with what we actually provide natively, and 
that my familiarity with GLX was insufficient to complete the job.  I even 
asked for help and/or comments.

All this, apparently, fell on deaf ears.
My August changes were based on the GLX that was then in our repository, and 
that glxProxy's build is broken since Alan's latest merge only furthers my 
point.

I have no objection to re-instating DMX builds.  Yet, on these grounds, I 
remain adamanant that SGI's glxProxy, as it currently stands, is unacceptable 
for inclusion into 4.5, with or without (un-)changes to make it build.

Marc.
+--+---+
|  Marc Aurele La France   |  work:   1-780-492-9310   |
|  Computing and Network Services  |  fax:1-780-492-1729   |
|  352 General Services Building   |  email:  [EMAIL PROTECTED]  |
|  University of Alberta   +---+
|  Edmonton, Alberta   |   |
|  T6G 2H1 | Standard disclaimers apply|
|  CANADA  |   |
+--+---+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-14 Thread David Dawes 
On Mon, Jan 10, 2005 at 11:00:22PM -0500, David Dawes wrote:
>On Mon, Jan 10, 2005 at 08:43:18AM +, Matthias Scheler wrote:
>>On Sat, Jan 08, 2005 at 07:37:29PM -0500, David Dawes wrote:
>>> The schedule for the next XFree86 release -- 4.5.0 is as follows:
>>> 
>>>26 January 2005feature freeze
>>>late February 2005 code freeze
>>>early-mid March 2005   release
>>
>>Is a list of changes for this release already available somewhere?
>
>Most changes are listed in the changelog file in the source tree.  There
>are some exceptions: for example, the latest Mesa/DRI updates, which
>should probably be added to the changelog.
>
>I'll be putting up a first draft of the 4.5.0 docs soon, and submissions for
>release notes content are welcome.

I've put up two sets.  One is built for the current snapshot and the other
for 4.5.0:

   http://www.xfree86.org/~dawes/4.4.99.x/
   http://www.xfree86.org/~dawes/pre-4.5/

Updates are welcome.

David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-19 Thread David Dawes 
On Wed, Jan 12, 2005 at 08:38:54AM -0700, Marc Aurele La France wrote:
>On Tue, 11 Jan 2005, Kevin E Martin wrote:
>>On Tue, Jan 11, 2005 at 02:15:58PM -0700, Marc Aurele La France wrote:
>>>On Tue, 11 Jan 2005, Marc Aurele La France wrote:
On Tue, 11 Jan 2005, Kevin E Martin wrote:
>Here's an explanation of the issue with a proposed fix to maintain
>backward compatibility:
>
>  http://sourceforge.net/mailarchive/message.php?msg_id=10290987
>
>I've tested my patch to make sure that it works fine on Linux.  I don't
>have an SGI box to verify that it still works fine on their systems.
>
Well, if I were you, I'd commit something like that ASAP.  I can deal 
with
the build issues, test case or no test case.  The point being that no one
will fix it if it doesn't build.
>
Longer term though, we need to look at glxProxy being more of an 
#ifdef'ed
derivative of GLX.
>
>>>Come to think of it, I'll be even blunter.  If DMX breaks every time GLX 
>>>is
>>>resync'ed, then there's no point in keeping DMX.
>
>>glxProxy was developed by SGI is almost 100% independent from GLX as
>>used in the rest of the X server -- the only shared code is from some
>>header files.  One of those headers was changed but not properly
>>#ifdef'd by SGI to maintain backward compatibility with previous XFree86
>>releases.  The patch that I suggested fixes the backward compatibility
>>issue.  This is all explained in the thread that I referenced in my
>>previous message.
>
>>Unfortunately, I just discovered that there is a much more significant
>>issue: you've made changes to glxProxy on 4 Aug 2004 that broke the
>>build.  I've attached a patch to make it build again.  However, I cannot
>>verify the correctness of the changes you've made, since glxProxy is not
>>my code.  As I mentioned above, the code was donated by SGI.  I would
>>strongly suggest reverting the changes you've made until you can verify
>>with SGI that your changes are correct.
>
>>If you do revert the changes back to the way they were originally
>>checked in and then apply the patch from my message to the dri-devel
>>list (see URL above), then glxProxy should build and work properly, and
>>it should also be backward compatible with previous XFree86 releases.
>
>SGI's own compiler could not build what was originally committed for 
>glxProxy, and GCC was also quite noisy about it.  Were this not so, I 
>probably would not even have noticed that there a much much larger issue 
>here.
>
>As I reported back in August, the GLX protocol understood by glxProxy is 
>significantly different from, and in many respects incompatible with, any 
>native GLX implementation we've ever provided.  In effect, we are being 
>asked to harbour and maintain a transport for a GLX implementation whose 
>end-points are not within our purview to support.  If you care to examine 
>glxProxy more closely, you will see that it is based on a separate, likely 
>SGI-internal, GLX snapshot.  I wouldn't mind so much if Xdmx were more 
>lbxproxy-like, but that's not the case here.  Fortunately, GLX is the only 
>extension Xdmx provides its own framework for.  It would also seem your 
>glxProxy testing only relied on a common subset of GLX.
>
>I also stated back then that my changes, in addition to fixing build 
>issues, also represented a first, necessarily incomplete, swipe at 
>re-aligning glxProxy's GLX implementation with what we actually provide 
>natively, and that my familiarity with GLX was insufficient to complete the 
>job.  I even asked for help and/or comments.
>
>All this, apparently, fell on deaf ears.
>
>My August changes were based on the GLX that was then in our repository, 
>and that glxProxy's build is broken since Alan's latest merge only furthers 
>my point.
>
>I have no objection to re-instating DMX builds.  Yet, on these grounds, I 
>remain adamanant that SGI's glxProxy, as it currently stands, is 
>unacceptable for inclusion into 4.5, with or without (un-)changes to make 
>it build.

That sounds like the way to go.  Re-instate the DMX builds, minus glxProxy.
When/if the glxProxy issues, including re-alignment with the GLX
implementation we provide natively, are resolved it can be reinstated.
If this doesn't happen, it should be pulled.

David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: XFree86 4.5.0 release schedule

2005-01-24 Thread Thomas Dickey 
On Sat, Jan 15, 2005 at 12:10:35AM -0500, David Dawes wrote:
> >I'll be putting up a first draft of the 4.5.0 docs soon, and submissions for
> >release notes content are welcome.
> 
> I've put up two sets.  One is built for the current snapshot and the other
> for 4.5.0:
> 
>http://www.xfree86.org/~dawes/4.4.99.x/
>http://www.xfree86.org/~dawes/pre-4.5/
> 
> Updates are welcome.

These changes correspond to xterm patches #185 through #199.

Improved behavior

 + change resource settings for color4 and color12, add some
   discussion in XTerm-col.ad

 + modify the criteria for disowning primary selection.  Previously,
   this happened anytime the cursor was moved before the end of the
   selection.  That would ensure that any insert/delete of char or
   line, as well as scrolling, would disown the selection.  The new
   criteria change this to checking if the operations would modify
   the data which is highlighted.

 + change default translations so a BtnDown which is not recognized
   is simply ignored rather than emitting a bell.  That makes it
   less obtrusive when the user tries to use a mouse which provides
   more capabilities than the X mouse driver supports, e.g., one
   with a horizontal scroll wheel.

 + modify to allow turning UTF-8 mode via escape sequence even if
   -wc option was not given at startup.

 + add menu items and corresponding actions for switching on/off the
   UTF-8 mode and Xft (TrueType) support.

 + modify FreeType support to allow resizing the font, in the same
   ways the window can be resized if fixed fonts are used.  The
   relative font sizes are derived from the fixed font sizes.

 + implement blinking text, using the timer for blinking cursor.

 + add translation to ASCII of commonly-used characters that groff
   translates to Unicode, when the font in use does not provide the
   corresponding glyphs.

 + modify constraints in form used to layout toolbar, to work with
   newer Xaw in XFree86 4.x.

 + make active-icon work properly when TrueType fonts are used, as
   well as when UTF-8 mode is used.

 + improve rendering for Xft, allow it to draw non-linedrawing
   characters such as "pi", which were drawn from internal tables
   with patch #180.

 + modify initialization of 256- and 88-colors so that colors beyond
   16 are normally not X resources.  This works around a hard-coded
   limit in Xt which breaks xterm when 256-colors and luit are both
   configured (report by Noah Friedman).

 + fix problem responding to session management events, e.g., which
   would make logging out very slow.

Modified behavior

 + enable utmpx support for NetBSD 1.6C and newer.

 + modify Help() to make "xterm -h" write to standard output rather
   than standard error.

 + improve error-reporting for root user by checking if $DISPLAY is
   set rather than using the useless message from X11 library.

 + improve $WINDOWID for configuration with toolbar by making it
   refer to the top-level shell rather than the parent of the
   current window.  For that case, the parent is a form widget,
   which does not have a name, which made the $WINDOWID not very
   useful as a parameter for xwininfo.

 + improve pattern used in uxterm to check for UTF-8 locale, e.g.,
   for HPUX.

 + modify uxterm script to use locale program to verify if the
   derived locale is installed.

 + add case to uxterm to accommodate locales ending with "@euro",
   e.g., [EMAIL PROTECTED]

 + for Linux, if IUTF8 is defined, e.g., on recent 2.6.x kernels,
   set the corresponding flag for the slave pty, to enable UTF-8
   interpretation of backspace in cooked mode.

 + modify faceSize resource to use a floating-point internal value.

 + modify XTerm.ad to set saveLines default to 1024.

 + change xterm version string to use __vendorversion__ where that
   is available, and "XTerm" otherwise.  Rather than reporting the
   version of X that was current when xterm was modified, it reports
   the version against which it was built.

New resource settings

 + add scoFunctionKeys resource, to match manpage.

 + add -fd option and resource faceNameDoublesize to specify
   double-wide fonts with Xft.

 + add resource showMissingGlyphs to outline places on the screen
   where a font lacks the corresponding glyph.

 + add resource showBlinkAsBold to control whether blinking text
   should be shown as bold or actual blinking text.

 + add utmpDisplayId resource to allow users to control whether the
   display identifier (display number and screen number) are
   retained in the connection information recorded in utmp.

 + add bellOnReset resource to allow users to disable bell which
   sounds on hard reset since patch #183 changes to

Re: XFree86 4.5.0 release schedule

2005-01-26 Thread David Dawes 
On Mon, Jan 24, 2005 at 09:52:37PM -0500, Thomas Dickey wrote:
>On Sat, Jan 15, 2005 at 12:10:35AM -0500, David Dawes wrote:
>> >I'll be putting up a first draft of the 4.5.0 docs soon, and submissions for
>> >release notes content are welcome.
>> 
>> I've put up two sets.  One is built for the current snapshot and the other
>> for 4.5.0:
>> 
>>http://www.xfree86.org/~dawes/4.4.99.x/
>>http://www.xfree86.org/~dawes/pre-4.5/
>> 
>> Updates are welcome.
>
>These changes correspond to xterm patches #185 through #199.

Thanks.  I'm adding this to the release notes now.

David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel