--=-OXDmr8f78A2oDTDO1N0K
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 X.org instead of
> XFree86.  We feel that targeting that switch for NetBSD 4.0 would be
> problematic, because X.org 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
> X.org, and porting fixes to our xsrc tree as necessary.
>=20
> X.org continues to be available via pkgsrc.
>=20
> In order to be able to switch to X.org after NetBSD 4.0 the following
> 4 targets need to be met:
>=20
> 1. Cross-building
>=20
>    Either by our existing reach-over framework, or auto-conf tools.
>    src/x11 support for compiling X.org is on the branch, but it needs
>    to be updated for the new releases of X.org.
>=20
>=20
> 2. Stability of the X.org code base
>=20
>    X.org 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
>=20
>    While X.org has support for newer and more cards, the
>    cross-platform support is lacking.  We should try to port our
>    existing servers that X.org 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 X.org
>=20
>    There is currently discussion within the X.org 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,
unfortunately.

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.

--=20
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQBDr/HSHUdvYGzw6vcRAlwcAJ46pIS+f/+kghAb7Swfr30BVk57NwCfUI+U
ikUTn6uFZ4D6CO8oBXtDQ80=
=xORC
-----END PGP SIGNATURE-----

--=-OXDmr8f78A2oDTDO1N0K--