To view parent comment, click here.
To read all comments associated with this story, please click here.
sure, xfree got things working, in the same way as windows "get things working". but in the end, would it have been worth it?
as for tricks, note my "or overtaking"...
but overall take it we agree, and its mostly my way of presenting things that your having a issue with (most of it was written based on the impression i have gotten over the years from news sources, and how i recalled things that that moment)...
I feel your pain. I do. From my personal experience, the quality of xorg server has gone way downhill since version 1.3.
For a good example, look at the status of intel driver, which incidentally is the one being mentioned in the article.
Here's a listing of intel driver related bugs in ubuntu (127 in total):
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel
Here's one that affects me:
http://bugs.gentoo.org/show_bug.cgi?id=212453
All right, maybe the bugginess of the driver is just due to the incompentency of intel programmers, and has nothing to do with xorg server.
It's easier to take a shot at people if they're nameless, isn't it?
I hardly think incompetent is the correct term in any sense in the cases of keithp, anholt, jbarnes, et al.
I congratulate you as you have obviously shown how X.org is inferior to XFree.
Have you filed bug reports for these issues? The xf86-video-ati developers (Alex Deucher and Dave Airlie) are pretty responsive and helpful.
I think you misunderstood my posting. Let me make this clear: I do not own bleeding edge hardwarre, so I don't expect something "too new" to work without problems. I have several BSD systems that run X.org on ATI hardware without problems. But this particular case affects my main desktop, so I'm a bit unhappy to see something [b[not{/b] working in "new" X.org that did work in "old" XFree86.
Ah yes, I forgot to mention that the Num Lock status LED sometimes deactivates when switching to a virtual console and back to X. The switching time is also longer with X.org than with XFree86.
I will surely do this as soon as I could do some diagnostics (doing some more tests with xorg.conf and trying a compiled version of X). Thank you for this advice.
Maybe you ask yourself: "Why didn't this strange guy file a bug report just after noticing that something didn't work as expected?" First of all, I try to solve problems on my own first - before I do bother someone. And up to this point (update on main machine from FreeBSD 5.4 to 7.0 including all applications), I did not have any (!) issue - everything worked as intended.
I'm just a bit disappointed. The speed gains from the system update are more than eaten by the slowlyness of the X startup... :-(
well stability comes with stagnation, the XFree86 tree just reimported a lot of the ati driver so it probably broke as well.
The thing is X.org drivers didn't support a lot of features, and you can't add features to a driver like dynamic monitor plugging and better detection code without causing some regressions. We trust that users report these regression so we can fix them instead of claiming that their one regression is the end of the universe.







Member since:
2006-10-08
but i think it was a modified license that was the final nail.
end result, a forked xfree from before the license change and xorg picked up speed after that.
Without wanting to sound impolite, I'd like to comment that XFree at least got things working (in "the old days", i. e. 3 years ago) that Xorg isn't able to do anymore. (Please see this note as an individual problem I'm having since I upgraded from FreeBSD 5 to 7, including an upgrade from XFree 4.3 to the newest version of Xorg: I can't get my ATI Radeon 9200 RV250 with the ati driver to run at 1400x1050 anymore, only 1152x864 is possible; and switch from console to X mode now lasts almost 10 seconds, while it lasted less than 2 seconds with XFree.)
Is catching up? I think it's already doing those tricks, and many more. :-)
The networking abilities have always been one of the most impressive things in X. Remote desktops and similar stuff were possible years before others had an acceptable network stack. :-)
To be precise, a home computer running UNIX / Linux is a multi user machine. It's just about how you enable two or more users to use the same machine at the same time. This isn't some speciality of X, but of UNIX / Linux in general.
This option will still be present, I think. At least, I hope. But well, I do use BSD, so it will take some time before the kernel mode settings developed for Linux will make their way into BSD. :-)