xorg7.3 [was: 7.0 preview slides]

[Coleman Kane]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Jeremy wrote:
> On Sat, Nov 03, 2007 at 11:41:32PM -0500, Mark Linimon wrote:
>  
>> The situation was that our import of 7.2 was delayed as we tested and
>> retested and retested, to get the framework working for the modular
>> code and ensure as few regressions as possible.
>>    
>
> Thank you for that.  I think it's unfortunate that X.org has decided
> to stop bothering with integration testing themselves but am glad
> that the FreeBSD ports team were able to do this for 7.2.
>
>  
>> It seems as though 7.3 is better for some people and worse for others.
>>    
>
> Having followed X within FreeBSD from XFree86 3.1.2 through to X.org
> 7.3, I can safely say that X.org 7.3 is by far the worst version as
> far as POLA violations and regressions are concerned.  I don't recall
> seeing anyone mention "better", though possibly those people aren't
> making a fuss.  It is difficult to understand how an "update" that
> broke generic features like xkb LEDs, xdm and mouse scrolling, as well
> as ati, mga and nv drivers (that I've personally used) could be
> considered an improvement.  I agree that the problem with xkb LEDs has
> been corrected, xdm has been partially fixed and I believe the nv
> problem has been fixed and there is an unofficial patch to work-around
> the MGA BIOS problem but this leaves the following regressions that
> I've noticed so far:
> generic:
> - Updating xdm over-writes local modifications
> - Impossible to disable wired-in modelines in the X-server
> ati (Radeon X200M):
> - VTY/X11 switching is dodgier (corrupts the screen more frequently)
> - system clock gets screwed up (it can lose several seconds) during a
>   VTY/X11 switch
> - DPMS display off/on can corrupt the display
> - The X-server often abort()s on shutdown
> mga (G550):
> - Impossible to specify a default initial resolution
> - HW cursor is broken
> - DPMS is broken
> (I can't currently test the systems with nVIDIA chipsets)
>
>  
>> In any case, as soon as 7.3 was out, I'm sure xorg lost interest in
>> bug reports about 7.2, and people were already asking us when the
>> next version was going to be in.
>>    
>
> I think it's unfortunate that X.org didn't spend more time testing
> X.org 7.3 before releasing it.  Hopefully X.org 7.4 will see an
> improvement in quality.
>
> I agree that the FreeBSD Project is not responsible for the shambles
> that was released by X.org but X.org 7.3 is definitely nowhere near
> the quality of the FreeBSD core software or the vast majority of
> ports.  Unfortunately, IMHO releasing FreeBSD 6.3 or 7.0 with X.org in
> its current state _will_ adversely impact the general perception of
> the FreeBSD Project.
>
> I don't believe it's feasible to roll back to X.org 7.2 so in the
> short term (for the upcoming FreeBSD releases) about all that can be
> done is to try and locate and apply fixes for the various regressions.
>
> The solution for the longer term is unclear - the FreeBSD ports system
> can't really handle a '-devel' variant of modular X.org - it comprises
> too many ports.  At the same time, the normal X.org ports can't be
> used for beta code because too many people will wind up running that
> code, courtesy of portupgrade or similar.  Maybe the GNOME or KDE
> groups have some suggestions on how to handle integration testing of
> large ports collections without adversely affecting the ports tree.
Maybe there could be a separate branch of the ports tree for people
who want the -devel X.org system... or keep the git-based ModularXorg
ports tree going like it was during integration.

In defense of the X.org people, I think that many of these
expectations on their project are somewhat unfair. I'm not dogging on
you for voicing your discontent, in fact the compilation of gripes you
listed above is probably one of the most helpful summarizations of the
X.org problems so far. I think that we need to consider, however, that
the X.org project (and the related freedesktop.org projects, which
should be absorbing some of the blame you direct at x.org) attempts to
overcome a number of serious hurdles placed in their path to building
a commercial-level GUI/Windowing system.

1) The lack of good documentation or support for the majority of the
hardware they are "expected" to support
2) The lack of personnel
3) The lack of comprehensive test configurations for every situation
under the sun
4) Many users are still living in (and expecting) the old XFree86
release model

Frankly, X.org and Freedesktop.org have vastly exceeded my
expectations of what such an open source, non-profit software project
is capable of. I can compare this against MS Windows and Mac OS X to
see just how much they have achieved without the helpful hand that
hardware vendors and others lend to Microsoft and Apple. We shouldn't
forget that all of these hardware vendors pay to make their hardware
work under Windows (whereas the freedesktop.org community effectively
"pays" to make all the hardware work as well as "pays" to develop the
environment).

There have been some bright points recently from industry. VIA, Intel,
and AMD/ATI have all committed some resources to the project. AMD/ATI
still has yet to release full sources/documentation (though they have
committed to doing so, as well as maintaining an open source driver
for their Radeon and Radeon HD products). Currently, it seems that
they've been rapidly pushing RadeonHD stuff into freedesktop.org. VIA
already maintains an open source driver for their integrated chipsets
with the freedesktop.org project. This driver is largely a quick-write
feature demo release and improvement efforts have been picked up
through the community-driven openchrome and unichrome projects. Intel
has long hosted an open source driver project for their integrated
graphics chipsets, also in the freedesktop.org tree.

Although this support exists now that never did before (part of why I
actually have some hope of getting "new" hardware working under X), it
still is nowhere near the level of investment that these vendors have
in Windows development. Their primary focus will always be on getting
32-bit Windows drivers performing better than their competitors.
Again, this community does all the work for X.org that these hardware
vendors pay themselves for Win32/Win64.

Also important to note is that even the latest version of MS Windows
Vista probably has less support for graphics hardware when running a
64-bit system. This goal is likely seen as more beneficial than the
goal of "open source drivers for X.org" and yet many of the vendors
haven't been able to get stable and complete drivers for the new Win64
system.

When I first upgraded to X.org 7.2, the AIGLX component wasn't working
on my Radeon M10. X.org would come up and freeze hard with a black
screen. Eventually I found that I needed to compile with
- -DWITHOUT_AIGLX in order to get it X to function at all. This was
eventually traced down to a locking problem related to differing
behavior between the Linux and FreeBSD drm kernel modules for radeon
cards. As soon as I had time to look into the problem, I found some
PRs on FreeBSD's site and bugzilla that had begun documenting the
problem (and had some preliminary patches). After applying patches to
src/sys/dev/drm, revising them, reposting, and retrying, the problem
was narrowed down to a couple patches to a few lines of drm_drv.c.
This fix is now in the Mesa3D mainline (though it doesn't look like it
has made it into FreeBSD HEAD yet). So every time I rebuild my kernel,
I need to apply a patch that I maintiain locally, which I am happy to
do until the fix gets into the tree.

When I first upgraded to X.org 7.3, the ati driver version 6.7.192
simply broke on my M10. I was able to revert back to 6.6.7, and that
one still worked (one benefit I like of the modular project approach).
Meanwhile, I got on the PRs again, and brought it up on the list. I
followed the HEAD of the git repository for the driver on fd.o, and as
others were also experiencing similar problems, the fixes got pushed
up there eventually. We all went to testing and provided feedback
quickly, and the xf86-video-ati port version was nudged a couple times
as fix confirmations were reported back to the maintainers.

This is how I am expecting an open source project to work. If it
breaks, then I put forth what extra effort that I have to figure out
how to resolve the problems. If I don't have the sufficient reference
to craft a solution myself, I volunteer some of my time as a guinea
pig to try other people's fixes. Many times, I might end up with a
patch from someone to try out. This is extremely helpful, as it is
naturally context-sensitive. I can modify the patch if it doesn't
completely fix the problem for me. The modular approach to X.org is
really nice, as it means the pieces are now managed individually. This
means that video drivers can continually be developed and updated,
adding new features without having to "live in the past" until the
next X release comes out. Anyhow, the X.org group put together
releases in a "monolithic fashion" up until the 7.1 release, as I
remember. These were molded along the same lines as the previous
releases, as well as the approach the XFree86 project took. They froze
the tree and entered a locked-down integration period which apparently
frustrated developers and users alike. They switched to their current
model with is not much more than "take the latest stable release from
all member projects, and bundle them together". There will always be
downsides and upsides to any development model. I think we should at
least respect X.org's decision to do things the way that they are done
now, and figure out a way to work with it.

We, as the FreeBSD Project, might want to try a different approach to
managing "our X releases", if the current model employed is faulty.
Maybe, rather than expecting to follow the X.org releases, we could
manage our own "FreeBSD X Release", which would simply consist of all
of the X.org component versions known to work well together under
FreeBSD. Perhaps, we could simply select these on every -RELEASE, or
similar tracker. If tagging X.org 7.3 as "our official X.org release"
is not working for us, then let's maintain our own list of X.org
packages that are the "FreeBSD official version". I would assume that
X.org's primary user base are GNU/Linux, and likely what is the best
selection to them is not necessarily the best selection for us. So
maybe we actually need to create a "FreeBSD X11 7.0-RELEASE" and stop
relying on the X.org project's decisions of what is "release" and what
is not. I imagine that we could organize efforts with the Dragonfly
and PC-BSD communities to benefit us all.

Your complaints are all valid, but if it really is such a problem, we
can't necessarily put the blame on X.org. We do have the ability to
put off our own release (even though we don't like that idea) until we
get a stable X11 system in our tree. If we rely upon X11 that much, we
should really absorb more of the burden of release bundling for our
user's specific needs.

- --
Coleman Kane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHLz43cMSxQcXat5cRAnNCAJ910lhIJzCDB6HnqZAJyeV4JhhuywCffKDn
D0ZosskvxKR4x8L5JwzvG74=
=KDbU
-----END PGP SIGNATURE-----