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.
So, who wants to smoke a bowl and celebrate?
... lots and lots of bugfixes. Glancing through the changelog extract linked to from the story, nothing really *new* jumped out at me. Not that this is a bad thing, bugfixes and increased stability/driver support is always nice. :-) I noticed a lot of things having to do with the Xprt server and having to do with 3d accel (drm, OpenGL man pages, nv driver tuning, etc.).
News for Geeks in Austin, TX
Here's a question that I want to address carefully, because it does sound a bit like flamebait.
Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency, enhanced programming environment, and a new, well defined and examined user interface? This would be going the Mac OS X route. In this model, I am not advocating abandoning X completely, but instead for backwards compatability run a rootless X server.
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
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"
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) !
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!
LKML has 1-2k emails per week. We have Kernel Traffic, Linux Weekly News kernel summary, kerneltrap.com, #kernelnewbies and there is generally one kernel update per day on linuxtoday.com. There are tons and tons of other articles about kernel development on Linux websites.
Compiling and installing a new kernel is easy enough that people are doing it on linuxnewbie.org
As a result the Linux kernel is one of the greatest pieces of software that exists today. People are willing to do a phenomenal amount of work to have their code included into the kernel.
We are at the point where even the most excelent code has to compete to be included. There were at least three different scheduler implementations for 2.5, two different VMs, and two different asynchronous io implementations. It is very good to be in the position where you can pick and choose what code will go into the kernel at this level.
On the other hand for Xfree had a closed email list until a year or so ago. There are about 250 emails per week to the Xpert mailing list. There are few websites with Xfree development articles.
Compiling and installing Xfree is difficult.
People constantly complain about X needing to be replaced. While there are real problems with Xfree, most of the stuff that people complain about to slashdot is complete crap.
To me this suggests that Xfree needs to concentrate on their PR skills. Xfree guys need to make development easier for newbies. Key developers need to have more interviews. They need to prove that developing X is just as cool as developing the kernel. There need to be more frequent updates--posted to linuxtoday hopefully.
Compiling and installing Xfree needs to be easier. I think about it this way, once you compile something, you are only one step away from developing. All it takes after that is to open up an editor and change something.
To me Xfree is as important as the kernel. Without it I would not use Linux. This is true for the great majority of Linux users. Xfree deserves more attention and credit than it currently gets.
Mr. Taco just wants us to hold of on our little /. effect ritual until further notice, after he has downloaded all of the archives!
--Andy
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
Heh, cool. I picked up a copy of the CVS version yesterday. I knew that as soon as I did that, a new version would come out..
;-)
I need this version, as it should have accelerated drivers for the Radeon Mobility chip that came in my Dell Inspiron 4100 laptop.
I just wonder how long it'll take to whip up a Debian package for it
1) Irix is not a microsoft product. Score 1 for SGI.
2) The truely high-end stuff tends to be done on unix type workstations. Perhaps this graphics card garbage is true in the home market, but not on the professional one.
3) If you're willing to pay for X (you're willing to pay for windows aren't you?) You can always buy implementations that support the latest hardware.
4) There are X-Servers/Clients with extremely advanced graphics features. Again, you generally have to fork up some cash, but you're willing to pay for windows, aren't you?
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!
In the future they may even come with DRM build right in. Think instant compliance no effort or even choice on the Linux users part.
They may not be open source, but I'll take features, speed, and stability over source anyday (if you really want source, you can always use the nv driver, too).
Microsoft and nVidia on Xbox:
nVidia: "But we don't want to change the Linux PC drivers to include drm. This wasn't part of the deal."
Microsoft:"Pray I do not alter the deal any further."
Is anyone else getting the feeling that ATI and their helpful specs are all talk?
Now that is a good question AC.
Aditionally does anyone know what state the open source driver is in? Is it developed more quickly or more slowly becasue of it's closed counterpart.
Novel theory: Modern Man evolved from psychopath
While I do appreciate the flexibility of X Windows, I honestly DON'T think the windowing system and toolkits should be these totally orthogonal projects, and the toolkits just "draw as they see fit" on a canvas that they expect the windowing system to render dumbly. This is the X model, inherited from the dumb terminal days. I have had this argument out several other times here on
I certainly believe firmly in the benefits of choice and competition, and agree with most
I appreciate what X Windows does for us, I just don't think it's the right solution for a desktop operating environment. Because of all the X apps out there, I think anything that comes out needs X compatibility as a backwards compatible route, but I don't feel that we should look to X Windows for the future. Just my opinion.
I think part of the problem is the fact that there never seems to have been any coherent work done on this. The windowing system oriented people who work on X say "the toolkit authors fault". The toolkit authors would say "it's your drivers or the limitations of X Windows"
Nope, read the thread I quoted and you'll see that gtk developer Owen Taylor agrees and that gtk 2.0 includes some of the optimization mentioned. The toolkit and X11 authors do work together on these things, and the toolkit authors have had a huge amount of input into the design of the XRender extension and the DRI infrastructure.
While I do appreciate the flexibility of X Windows, I honestly DON'T think the windowing system and toolkits should be these totally orthogonal projects, and the toolkits just "draw as they see fit" on a canvas that they expect the windowing system to render dumbly. This is the X model, inherited from the dumb terminal days.
Actually that's not the X model (BTW, X wouldn't run on a dumb terminal--even vi wouldn't run on a true dumb terminal (ie glass tty)). The X model is to provide high-level graphics primitives to the application, which then submits them to the server which can turn them into whichever low-level calls are most efficient on the hardware in question. Not only that, but the library used to submit those request can (and does) batch them together so that the application writer can have a simpler model and still get efficient code--for instance, multiple XDrawLine calls are batched by XLib into a single XDrawLines call that's sent on to the server, saving on round-trips and in some cases saving on bus traffic to the video card by eliminating redundant traffic. Or servicing those high-level requests in whatever manner is most efficient for the hardware in use.
Highly efficient graphics can be done this way. Witness SGI, who were for years the undisputed leaders in the graphics field. They used X11.
But think of X as being more of a device-driver with a unified API, the GUI is to be built on top of that. It's a highly reasonable and well considered model that is ideal for building the high-performance GUIS of the future on. Far better than e.g. a framebuffer, which is already obsolete (doesn't handle many 2D features like overlays & alpha blending, doesn't do 3D acceleration, doesn't allow for hardware security a la SGI, doesn't handle hardware video decoding, etc) and is low-level enough that you can't have the driver do intelligent optimizations without rewriting the apps. And designed with the foresight to be extremely flexible.
Sumner
rage, rage against the dying of the light
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.
Now, about latency. If you compare local access to X11 with local access to, say, Windows or OSX, I don't think you'll see practically significant differences. (Well-written applications will use shared memory for any kind of bulk data transfer.)
About the graphics model. The X11 graphics model is complex. It really does expose a lot about the underlying graphics hardware to you and it gives you pixel accurate rendering. That was crucially important in the 1980's and has served X11 extremely well for nearly two decades. Today, it's less important, since you don't get a lot of low-depth screens anymore. I would expect that in the future, the RENDER extension will become the predominant graphics API and the core X11 graphics APIs will receive less attention. Implementing the core X11 graphics doesn't need to be a lot of code, and you don't have to worry about all the oddball bitmap formats if you don't want your applications to run with oddball display devices. But in some markets, that kind of control is important, and X11 provides it in a portable and network transparent manner.
Overall, X11 is an old system and has accumulated some cruft. It's also a complex system because it does some really nifty things that neither Windows nor MacOSX have really tackled well. On balance, I think it's still a very modern network transparent windowing system, and if you were to design something with similar functionality today, it wouldn't look all that different or be all that much simpler. So, I vote for keeping X11, not because it's widely used, but because it's actually quite good. And I hope people will spend the time to understand X11 better. The people who designed it were very good; give them the benefit of the doubt.
Those are problems with the toolkits. None of the modern toolkits (Gtk+, Qt, wxWindows, FLTK, Mozilla, etc.) use X11 very efficiently. The redraw logic in Gtk+, Qt, and Mozilla is, in fact, in violation of X11 guidelines. The reason is that these toolkits are mostly written with a Windows GDI mindset, either because that's what their authors are familiar with, or because they want to achieve cross-platform compatibility and it's easier to treat X11 as a second-class citizen.
applications all have inconsistent look and feel,
X11 is not a user interface or desktop, it's a network transparent windowing system. If your user interface is inconsistent, you only have yourself to blame for it: don't run X11 applications written for different toolkits or desktops. You get similar inconsistencies if you start running Motif or FLTK or wxWindows or Mozilla applications on Windows or MacOS.
And if you say that I need to tweek it to get it as fast as MS, then MS wins.
I'm posting this from Galeon running on a vanilla Debian installation on a 200MHz Pentium with 64M of RAM and a 5 year old graphics card. Windows wouldn't even boot on this configuration without excessive paging, and IE is a dog. In the past, all the graphics benchmarks I have done ran faster on good X11 implementations than on Windows. So, I challenge your implicit the claim that Linux+X11 is less efficient than Windows. But even if that were the case, on 1GHz machines with 512M of RAM, any such differences are academic.
However, the Gnome and KDE desktops are comparatively slow and resource intensive, probably similar to recent versions of Windows. I couldn't run them very well on this machine (although they do run). That is something you will have to take up with the authors of those desktops. But they, too, are designed for modern machines, where it really doesn't matter.
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.
>So the option is, wait a few more years for
>Xrender to be completed, or check out stuff like
>directfb and berlin which claim to do what
>Xrender will do years from now.
Well, Berlin is at 0.2.2, and requires some sort of underlying graphic system - directfb, ggi, sdl or glut.
Both sdl and glut require an underlying graphics system as well, usually X. So those two are out if you want to do away with X.
Now on to GGI - at least the library (libGGI) is release quality. This is actually just a userspace graphics library that sits on top of an underlying system - X, svgalib, fbcon or glide.
We'll assume you want acceleration, freedom from X, and reasonable hardware support. So out go X, svgalib, and glibe. FBcon can be accelerated, as long as it used kggi, which is currently only available from CVS.
DirectFB also depends on FBcon, but it is does at least have what looks like a near final release.
So, our choices are:
Berlin on DirectFB on FBcon
Berlin on GGI on FBcon
DirectFB on FBcon
We may want to nix Berlin on GGI on FBcon, if only for the sake of having something which is SOMEWHAT near completion.
I'm not sure where you're getting this figure of "a few years" for Xrender to be completed, as Keith doesn't have timeline information on his website at all, but alpha compositing, anti-aliasing, and sub-pixel positioning are all written and included in the current XFree86 distribution. As the primary author states, the big pieces left are polygons and image transformation. Given that the initial discussions were at the 2000 USENIX Technical Conference, I'd say their progress is remarkable.
>Whats the best option? People want alpha
>channeling, scaling and OSX like effects,
>alternatives claim to be able to do it now, they
>port GTK and QT, and they claim to be compatible
>with X.
Xrender is already able to do alpha channeling and anti-aliased text, which are a major part of the deficiencies. Image transformation for things like scaling are forthcoming.
The alternatives, as discussed above, are not at a final release stage, rely on a linux only graphics layer (FBcon), have a narrower range of hardware supported (or supported well), and have a signifigantly different paradigm, thus complicating porting existing toolkits.
So is moving to a completely different toolkit, possibly with an unsolidified API, with the added headache of bringing all the drivers up to the same level of stability and performance as XFree86 already enjoys the "best option"? Or is the best option really updating toolkits to take advantage of the features available in XRender now, and planning on supporting the upcoming portions of the extension as they become available?
Matt
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.