Slashdot Mirror
Xfree86 4.2.0 Out
According to david_eliasson,
Xfree86 v4.2.0 is out, but it'll probably be awhile before all
the mirror sites have sycned up with the release, so you may want
to just enjoy reading that changelog for a couple days before you
bother getting the whole archive.
Yet Fink just came out with its 0.3.2a distribution-- hopefully they'll be able to bring these packages up to date quickly, so all us OS X users can enjoy the same XFree goodness as y'all.
Don't know about the status of dri in xfree86 4.2.0, but sli support for voodoo 5 should be in dri cvs. Not sure about how well it works tho.
Is anyone still maintaining XFree86 3.3.x?
I know that Debian people are patching 3.3.6 continuously. I get -v3 updates pretty often. And that is good, because 4.0.2 didn't support my crappy TP560+trident. (AFAIK Debian people fix X themselves, and port fixes from XFree86 CVS).
fucktard is a tenderhearted description
I think its pretty significant that they've finally made the system work with the old Rage cards. They still sell those (for about $12), and they have a strong hold on the non-gamer market. Heck, I have one on the workstation I'm working on now (don't worry, I've got a game station too). It could help convince businessmen with old Pentiums that they should use Linux if they can get it to work with their typical hardware on the first try.
Mod me down and I will become more powerful than you can possibly imagine!
Here's a nicely formatted list of mirrors for you lazy bastards ;) :)6
Let's make the slashdot effect on xfree86.org a little more bearable
ftp://ftp.calderasystems.com/pub/mirrors/xfree86
ftp://carroll.cac.psu.edu/pub/XFree86
ftp://ftp.cs.umn.edu/pub/XFree86
ftp://download.sourceforge.net/pub/mirrors/XFree8
ftp://ftp.freesoftware.com/pub/XFree86
ftp://ftp.infomagic.com/pub/mirrors/XFree86
ftp://mirror.sftw.com/pub/XFree86
ftp://phyppro1.phy.bnl.gov/pub/XFree86
ftp://ftp.rge.com/pub/X/XFree86
ftp://ftp.valinux.com/pub/mirrors/xfree86
There are people working on adding a new rendering model that does antialiasing and sub-pixel addressing. "People" being mostly Keith Packard.
There is no reason you can't do that to X, in fact if you compare things like xlib to Gtk--, or Xt to Qt there has been huge progress. Oh, and there is GNUStep too, which is mostly like NeXTStep which is what OS X is based on...
That is the hard part. In part because backwards compatibility works against you.
I think OS X has a lot going for it, but the biggest thing really is that the apps do mostly work alike, which is rather unlike X11. I know I'm partly at fault since the X11 apps I worked on (xtank and w3juke) are not much alike :-)
One of the major problems I had running XFree86 on my laptop was having to switch between a port replicator (aka docking station) and using the laptop's display. For those of you that don't know, a port replicator lets you use a standard monitor, keyboard, mouse, etc. Switching between various XF86Config files got to be a royal pain in the arse.
So... those with laptops give this option a try in XF86Config:
Option "UseBIOSDisplay"
No. Antialiasing and transparency are most of the way into the X server already. Any enhanced programming environment or better user interface is unlikely to be more difficult to implement on top of the X server than atop some from-scratch thing.
Basically, the X protocol does all the hard parts of a window system fairly nicely. Its rendering functionality was until recently unfortunate, but Packard's client-side rendering via the Render extension appears to be adequate for anything anyone wants to do with GUIs these days.
The current client-side libraries are not so good, but this can be fixed without changing the X server or protocol. See XCB for one proposed step in that direction.
IMHO, if one-tenth the energy that was put into whining about X and flailing at never-quite-ready replacement rendering systems went into these sorts of things instead, we'd have a nicer-than-Mac/Windows desktop GUI for free by now.
The problem with X11 is, in part, the separation of client/server; this causes extra latency and a heap of context switches
The context switches aren't a significant overhead. They weren't even a significant overhead in 1986 when Sun first started spreading FUD about this (at the time, Sun was trying to push NeWs over X11). See e.g. Jim Gettys' posts in the "rendering model in X" thread in the Xrender mailing list archives
It's not all sunshine, he's willing to own up to places where X needs improvement (exposure lists are a big one, througput for e.g. texture mapping is another), but it's way better than a lot of people claim. And Xrender and DRI address the vast majority of the problem cases very effectively.
Sumner
rage, rage against the dying of the light
Anybody try what was in CVS?
I compile CVS version about every week or two. Not many tdfx related changes (I have Voodoo3), but 4.1.0 was worse (Xv _and_ OpenGL). You should upgrade if you have ATI card (for example Radeon VE works only with CVS). There are still problems with Radeon - for example - anyone tried to run RTCW multiplayer demo 1.1 on Radeon? Whole system hangs (every time) !
Check out Evas. It features an excellent, very easy to use/simplified API, hardware acceleration, anti-aliasing and all of those cool things and is designed in such a way that you don't need to be concerned what kind of hardware your app will run on - evas will scale accordingly. Plus, there's rumors that rasterman is building an Evas client-server API that could almost supplant X, while not necessarily supplanting X...I think it's a pity not enough people are looking at this excellent library.
Enlightenment 0.17 is built upon Evas, and from my experience with it, it does run very fast.
Am I a hipster-doofus?
Its really easy to fix: webfonts-1-3.noarch.rpm
Make sure to read the MS Eula included.
I found additional documents looking through the website. These are much more interesting to read than the changelog.
The README
The release notes
Installation details
Driver status
Enjoy!
The reason X has a bad image is that most Linux distros by default *don't* have good fonts.
The reason for this is that there are simply no good fonts under a sane license out there.
If you find any good fonts that are at least freely redistributable for both commercial and noncommercial purposes, please let me know and I'll make sure they get into some distros.
This message is provided under the terms outlined at http://www.bero.org/terms.html
hi, i have tried the CVS for some while now and yesterday went to the RELEASE version. only disadvantage is that the CVS used to have
freetype 2 version 7.0 and 1.5 days before they released xfree 4.2.0 they downgraded it to version 6.3 (it was kinda disapointing imo)
e.g. like 'hey we are behind release date, lets agree and downgrade some of the stuff to get the release out'
Everything from how the Windows decide where they want to be to really obnoxious icon placement just irks some people (myself and many people I know) about X11 and friends.
...).
I agree that it is obnoxious when windows and icons are not placed where you want them.
But get your facts straight dude! It is the window managers fault and not X11's. The X server just does what it is told, layout policy is handled by the window manager just like the widget policy is a function of the toolkit (gtk, Qt, motif,
If you had read the thread I mentioned in the article you replied to, you'd see the anser to this one:
> > Not to be too non-technical...
> > > > If the protocol overhead is so small, why can't my 1200 mips (600mhzPIII)
> > machine resize windows without widgets streaking? My 486 could do
> > this fine running MS Windows. Is this because many widget toolkits (GTK,
> > QT) use XPutImage? There must be some way to speed things up.
blame your widget set. basically (sorry owen and co on the list) gtk a
(and i presume qt) dont render optimially at all. the do a semi-decent
job.. EXCEPt for opaque resizing, and when redrawing is more than a few
lines and boxes... this is a toolkit issue and imho the current set of
toolkits (motif, qt, gtk etc.) do a god-awful job of this kind of
stuff. right now i have silky smooth "opaque resize" stuff working here
with enlightenment 17 - but i do the rendering completely differently
to gtk/qt - its all a canvas and thus the rendering happens in a
"backing" so updates are smooth. on todays hardware this is the best
way to do it and have almots no artifacts ANd retain speed.
> "Streaking"? Are these opaque resizes? Alot of apps aren't doing
> event compression. They repaint the whole damn window every time they
> get an event. They could have at least checked that there weren't
> more events in the queue and got rid of them instead of handling each
> one in turn.
true. its a very bad thing that there are a LOT of apps that behave like
this... a LOT. some of the most commonly used are guilty of this
(netscape for one....)
If you enable Silken Mouse in XFree86 4.0 and later, this should be fixed. Certainly an implementation issue and not an architectural issue (i.e. not a reason to throw out X and start over)
These aren't X11 problems but GUI problems, GUI standardization is certainly a huge issue. But, gtk-2.0's accessibility enhancements include excellent keyboard support and some steps toward simplifying and unifying look&feel. KDE is moving in that direction as well. Obviously you need to use a single unified UI on your desktop, but having two decent ones available to choose from is not a bad thing (not to say that either is decent yet, but they're both heading there rapidly).
Sumner
rage, rage against the dying of the light
This is of course completely dependent on whether your window manager "grabs" the X server while doing a 'move window'. Switch that off, and your windows will update asynchronously. There is a minor performance hit on some (mainly older) graphics cards when this option is selected. Personally I can't tell the difference on my G450.
The other thing of note is how
(above) appears to sound knowledgeable whilst being completely and utterly wrong. (S)he is simply spreading FUD (why, I don't know - perhaps (s)he likes to appear clever when (s)he isn't). Don't you just love it when people try to use stuff they don't know about to advance their personal agenda ?
Almost as much foot-in-mouth as Simon.
Physicists get Hadrons!
As a minor player in the original XFree86 work (back when it was X386) I can say you are wrong. The work started before linux was a viable platform, instead it was SVR4 on 386's - but one of the earliest goals of the project was, and continues to be, mutli-platform compatibility. That's why you can run XFree86 on SCO, SVR4, *BSD, Solaris and Linux. Just because they don't focus *ALL* their efforts on linux doesn't mean they were stuck up snobs - if anything you are the stuck up snob for suggesting that they should dedicate themselves to Linux alone. A monoculture - whether it is microsoft or Linux is not a healthy environment.
When information is power, privacy is freedom.
There's "SLI support," but it is non-functional (Glide3 SLIAA-1-0-branch and DRI tdfx-2-1-branch contains Bill White's work from December 2000). It was never finished, though (I think we all can guess why).
The XFree86 source tree looks absolutely horrible the first time you try to find out how to compile it.
;)
I looked at the make files for a _long_ time before I though "hell, let's just do make World and see what happens".
X built without a single hickup. Why doesn't the README say "If you're using Linux, just do make World and it'll work" ?
Can you hear me, Major Tom? I'm not the man they think I am at home...
We're already shipping those - they're in the
"ttfonts" package in Red Hat Linux. (Taken from
OpenOffice CVS a while back).
This message is provided under the terms outlined at http://www.bero.org/terms.html
Cursed be Wind River for all eternity.
Ooh, moderator points! Five more idjits go to Minus One Hell!
Delendae sunt RIAA, MPAA et Windoze
DirectFB just provides access to the framebuffer. If you want to build a full UI on top of the framebuffer, you'll need to code font support, widget sets, window management, etc. In other words, you'll need to start over and build the equivalent of Berlin from the ground up on top of DirectFB, except it won't be accelerated.
Check the docu, you need to have it compiled into your X server and might need an Option line in XF86Config-4. If it's on, you'll get:
(==) R128(0): Silken mouse enabled
or similar in the XFree86 output.
If you're running a kernel with good latency (e.g. 2.4.17 + Andrew Morton's LL patches, I use 2.4.17-jl11) you'll no longer see any mouse cursor dragging/skipping/etc problems. If the kernel has bad latency, there's nothing X can do about it.
Sumner
rage, rage against the dying of the light
Unless they royally screwed something up in the past few months, a show stopping XVideo bug with tdfx that was in 4.1.0 was fixed. I've been running CVS for months because of the bug. Basicly, if UYUV or YUY2 colorspace overlays were opened with the tdfx driver, the whole thing would crash out.... Shortly after then it was fixed in CVS, but it takes so long for them to release, I just had to use CVS. So if you use tdfx and certain media programs crash your X (particularly DivX videos are notable...), this is a *very* cool update...
XML is like violence. If it doesn't solve the problem, use more.
A release usually included binaries, and the 4.2.0 ones are where?
As other fellows have commented, the binaries are created on your hard disk after you 'make world'. Compilation has become much easier since the 3.x series.
Will I retire or break 10K?
Of course, even on a fast connection, it's painful to run vi on a terminal that lacks cursor addressing. But there's a slightly improved version of the ADM3 (the ADM3a) that has this feature. And it just so happens that the ADM3a was the standard terminal at UCB when Bill Joy was there. Which is why the first version of Vi only ran on the ADM3a. And Vi still has minor ADM3a-specific features, such as using the h, j, k, and l keys for cursor control (the ADM3a had little arrows painted on these keys).
Come to think of it, here we find the whole origin of the Vi/EMACS divide. Twenty years ago, UCB was a state institution with cheap "dumb" terminals, and MIT was a private institution with expensive "smart" terminals. Each institute produced a corresponding text editor.
Essentially, it was an athena app that you would use to make minor adjustments and then print a modeline to stdout. You'd just have to edit the modelines in the XF86Config and it would work.
Someone on one of the linux irc channels probably could tell you the name of it and give you pointers. It'll solve those problems with the screen being offset or crooked and whatnot.
Those who can't do, teach. Those who can't teach either, do tech support.
I've not used MetroX myself, but I did use AccelX some time back on an S3 PCI video board I had. It sucked. It was horribly unstable, much more so than XFree was at the time (3.3.x then). For all their talk about high performance and stability, IMNSHO their products didn't bear out their promises. And from what I've heard from some other people, they still don't.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Actually there is, as long as you don't want to rotate the text or anything like that. However there is a font server that the X server normally uses to get fonts, that only supports bitmaps. That could be fixed without impacting too many apps.
There is an X extension to do antialsiased text, in part to get sub-pixel addressing, and in part (I assume) to avoid finding some long dead application that would break... (like something that relies on XOR to erase things, or...)
I think you're thinking about xvidtune
--
all of KDE3 :-)
now, styles aren't using it yet, but qt3 has more or less ripped out all of the hacks it used to have and is using RENDER extensively throughout it's codebase for these kinds of operations. KDE2 uses RENDER as well, in a more limited fashion, to allow antialiased text.
The new X11 Rendering model is here, and it's real, and apps are using it already. Not all of them, not to it's full abilities, but that's changing fast already.
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Backing store (as used by X) copies the part of the screen that is being hidden by a new window to an off-screen area. It can then copy parts of it back when that obscuring window is moved or removed.
Double buffering lets the program draw into the offscreen area, and then it copies that offscreen area to the screen (either automatically or on a program command).
Backing store sounded like a good idea when most overlapping windows were assummed to be pop-up menus. It does not work if the underlying window changes (which almost all modern toolkits do, due to them copying Windows's highlighting of menu titles, or due to the focus moving to the window). If the underlying area is drawn to, X is supposed to forget the backing store, but XFree86 seems to not do this, this indicates how little backing store is used that nobody bothers to fix this.
Double buffering is much more useful, though it uses a lot more memory. If the entire image of the window is stored then transparency of the windows is possible without having to draw them all from back to front. For this reason all X and Windows hacks that produce transparency of all windows use double-buffering, also OSX uses it. NeXT used it too. It is also possible and useful to double-buffer only the visible portion of the window, this is what OpenGL and probably DirectX and all other 3D systems do because the offscreen area is the same size as the screen, but you lose the ability to move or composite transparent windows without redrawing.