Date: Mon, 05 Nov 2007 11:00:55 -0500 From: Coleman Kane <cokane@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Mark Linimon <linimon@lonesome.com>, x11@freebsd.org Subject: Re: xorg7.3 [was: 7.0 preview slides] Message-ID: <472F3E37.7050903@FreeBSD.org> In-Reply-To: <20071104065202.GA97281@server.vk2pj.dyndns.org> References: <4727BE96.9020804@FreeBSD.org> <20071102173425.GB5282@graf.pompo.net> <472BB699.6070507@FreeBSD.org> <20071103005145.GA50846@FreeBSD.org> <472BDF06.5050700@FreeBSD.org> <1194122492.92719.56.camel@fbsd1.dyndns.org> <20071104044132.GA10723@soaustin.net> <20071104065202.GA97281@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?472F3E37.7050903>