Subject: Re: XFree86 vs
To: Valeriy E. Ushakov <>
From: Eric Anholt <>
List: tech-x11
Date: 12/26/2005 05:36:18
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-12-15 at 07:34 +0300, Valeriy E. Ushakov wrote:
> Core has considered the question of switching xsrc to instead of
> XFree86.  We feel that targeting that switch for NetBSD 4.0 would be
> problematic, because tree undergoes some major changes, like
> e.g. switch to GNU auto-tools.  For NetBSD 4.0 at least we want to
> stick with XFree86 as our xsrc, while continuing to track progress of
>, and porting fixes to our xsrc tree as necessary.
> continues to be available via pkgsrc.
> In order to be able to switch to after NetBSD 4.0 the following
> 4 targets need to be met:
> 1. Cross-building
>    Either by our existing reach-over framework, or auto-conf tools.
>    src/x11 support for compiling is on the branch, but it needs
>    to be updated for the new releases of
> 2. Stability of the code base
> has introduced quite a few regressions over XFree86 code.

Most of the regressions I've heard about have been in the Radeon
disaster^Wdriver.  There's a patch in the pipeline that should be fixing
a lot of those.

As usual, there's bugzilla, but it's *really* not being watched well
enough.  I would encourage people to harass us on IRC if there are
patches that need to be committed.

> 3. Native server support
>    While has support for newer and more cards, the
>    cross-platform support is lacking.  We should try to port our
>    existing servers that does not have.

Now that modular is finally out, and we're liberated from imake, I'd be
happy to help anyone get tested drivers pushed into the X.Org tree.

> 4. Strategic direction of
>    There is currently discussion within the project about
>    deleting the pseudo-color display support code from the Xserver.
>    Such changes will automatically break support for older hardware.
>    While we understand that in the future older cards may not be
>    supported we believe that this change is immature.  The earlier we
>    start porting NetBSD servers (see #3), the more chances we have to
>    have impact on that decision.

Could you point to discussions about pseudo-color display support
removal?  I haven't heard of such a thing, and in fact we've talked a
good bit (just not written the code for) using Composite to support
pseudo-color-demanding apps on non-pseudocolor displays.  Pseudo-color
hasn't left the list of things that still need to be thought about,

I have heard a few people saying the want to axe the pseudocolor overlay
support, I think.  (that's where you've got (usually) 32 bits per pixel,
with 8 bits being 255 colors in pseudocolor and one signalling that the
display should show the 24 bits of true color for that pixel instead.
Little hardware supports it, and the number of users is smaller).  I
don't think that would fly, though.

Eric Anholt                               

Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Version: GnuPG v1.4.2 (FreeBSD)