New XFree86 snapshot - 3.9.17 295
MartinG was one of many people who wrote with the news that XFree86 has released 3.9.17. It's availible on their ftp server and features some relatively minor changes since 3.9.16. Still leading up to the promised 4 release, but that should be happening in the near future.
X development too closed (Score:2)
Re:KDE (Score:1)
Re:KDE (Score:2)
You might want to look into how this stuff works a bit more before you spout off like that...
--
Re:X development too closed (Score:1)
The main reason I migrated to LINUX was for X.
I like the idea of a x-Server/WM/desktop independant of the OS.
Not that the other GUI's are bad. Just poorly implemented.
I am very happy (Score:1)
>o Add GeForce/Quadro support to the NVIDIA driver.
has anybody tried this out yet? does it work? I'm 200 miles away from my machine, so I can't...
Re:KDE (Score:1)
Actually i am aware that KDE runs on top of X i gust prefer using KDE and find that KDE's feature are better that X
That's like saying "socks are better than shoes".
Re:KDE (Score:2)
How can the features be better or worse? They're two totally different things.
X is a display server, it manages video card and input devices.
KDE is a window manager, is manages the look/feel of windows, their movement, etc.
How can you say what you're saying? Window Managers cannot be better or worse then X, as they are not equal.
Don't compare apples to oranges.
-- iCEBaLM
Re:KDE (Score:4)
For those not very familar with the X Windowing System (the linux user group of north alabama has a good writeup by the way, drop by http://luna.huntsville.al.us/faq and go to the X section), a quick briefing of what makes up X:
- X server: talks to graphics system, keyboard, mouse, etc
- X clients: all other programs that talk and request resources from the X server
- toolkits: scroll bars, text input, all sorts of things like this. GTK, QT, and motif are examples
- window managers: let the user manipulate the windows present on his display. TWM, FVWM, WindowMaker, Enlightenment, KWM, etc. (KWM is KDEs window manager)
Up until a few years ago, open source "deskop enviroments" weren't really available (GNOME and KDE are opensource examples). These enviroments often use a toolkit, consistent ui guideliness, and have methods of letting apps talk to eachother easily. They also sometimes include window managers (KDE uses KWM, and recently others can be used as well; GNOME has always sought to be "window manager independent," meaning that if you have a supported wm, you get extra features. If not, you just don't have the extra features.
Hope that clears a few things up!
cfrost@hiwaay.net (my domain is currently down...)
Re:I am very happy (Score:1)
Don't feed the trolls. (Score:1)
Charles Miller
Re:KDE (Score:1)
Re:I am very happy (Score:1)
has anybody tried this out yet? does it work? I'm 200 miles away from my machine, so I can't...
Err. . . why would they release it if it didn't work?
Re:KDE (Score:1)
Re:Numbering (Score:1)
3.9.17
that will be the way it goes
Re:KDE (Score:1)
Well, everything past "X clients" should be a subcatagory of it, not on the same level.
Anyway, the html version of LUNA's X explanation (written by Jeff Gehlbach, creater of the gnu utils "--dammit" patch) is available at http://luna.huntsville.al.us/faq/faq-3.html#ss3.3 for a quick link.
cfrost@hiwaay.net
Re:I am very happy (Score:1)
DRI? (Score:1)
Re:Numbering (Score:1)
PS these are not real numbers just a way of writing versions.
Re:Numbering (Score:1)
Re:Numbering (Score:1)
First, just as the third number has gone above one digit, the second might as well. (ie, 3.10.1). Not that I think they will, as the third number has a long way to go, and they claim to be fairly close to releasing 4.0 (which does seem to nicely follow 3.9.x).
Second, the version number is not a mathematical value which needs to be "correct" in a numerilogical (sp) sense. Rather, think of it as three distinct numbers, using a period to delineate the numbers. The major version number, the minor version number, and the minor fix number. Merely stuck together into one symbol which represents the version. Not a number.
LoppEar
Re:KDE (Score:1)
if you want to be picky, that's like saying shoes are more better than socks....
but that would be picky
Micah
Re:I am very happy (Score:1)
Release = not everything is guaranteed to work.
There ain't no guarantees - expressed or implied!!
Check out my photography @ page.switchco.com/~image [switchco.com]!
What's the advantage? (Score:3)
It seems that loadable modules for font rasterizers, etc., would make the initial setup easier, but once that is up, what's the difference to someone who doesn't use 3D or any other sort of "multimedia?"
Re:Maybe someone should fork off the XF|86 tree (Score:3)
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Re:DRI? (Score:1)
Re:What's the advantage? (Score:1)
The point of XFree 4 is to add GLX/DRI support for those people that *want* 3D gaming.. if all you do is 2D apps I don't expect much to change.. maybe it'll be faster.
The license is a non-issue, good point still (Score:3)
XFree is being developped under the BSD development model -- cathedral style -- and released under a BSD (X) license. The two are not necessarily bound.
Apparently, the XFree developer fear that people start looking at their development sources. I remember, a few years ago, they only made time-bombed binaries available for their beta-version! Given the success that projects like Linux, KDE and Gnome have shown using a completely opposite strategy, we have every reason to believe that such a model would work better.
And no, before someone mentions it, I'm not karma-whoring: I actually considered working on XFree, I was interested in working on TrueType support, which has been since then released. But I could'nt even find a mailing list archive from their site! So I had no way to find out what was being worked on, which issues there was, or who to contact.
G200/G400 (Score:2)
Or do I download the glx module from the glx website and use that one?
Re:Numbering (Score:3)
that's what the version number means.
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Re:DRI? (Score:2)
you can do direct rendering with matrox and rage pro cards already with xfree 3.3.5
Re:I am very happy (Score:1)
Re:personally (Score:1)
Creating batch files, hoping I didn't make a typo. That's the way to live.
XFree86 sucks. (Score:1)
Re:Numbering (Score:1)
Version numbers are not decimals, but instead are tuple numbers. Ignore that it is a period that seperates the numbers, it could be a slash, a dash, or anything else. File Paths are another form of tuples, as are IP numbers...
Software announcement (Score:1)
------------------
Re:Numbering (Score:1)
Think of the people who write dates like 1.1.2000 or the European mathematicians who are the reverse of us "Stupid Americans".
Where we write...
1,000,000.4321
they write...
1.000.000,4321
The only reason to choose calling X version 3.9 was to let you know that it's going to become 4.0 soon. It can go to 3.10 before 4.0 if it must, even though it throws off the illusion that 3.9.x represented.
Digital Wokan, Tribal mage of the electronics age
Re:What's the advantage? (Score:2)
Re:What's the advantage? (Score:1)
Digital Wokan, Tribal mage of the electronics age
Re:Yes, time to fork. (Score:2)
In any case I'd wait for 4.0 before forking if I were you. Unless it really takes forever to turn up, that is. Forking right before the XFree86 team comes out with a major new update seems like a recipe for needles integration trouble.
And finally: only the current copyright holders can change a license (and only if they all agree about it). Others need to stick to whatever they got in the first place.
--
From the XFree86 web page (Score:2)
XFree86 3.3.6 will be released in parallel with 3.9.17 as well.
That means we should be getting a new version of the stable server shortly as well. Hopefully, many of the development features that can be integrated will be integrated.
And to the naysayers, the X people do a fine job with a very old piece of software. E-mail your suggestions to them, not your complaints.
Re:Software announcement (Score:1)
Slashdot announces news and important software releases.
Freshmeat announces software releases and important news.
3.3.6 (Score:4)
bye,
-jimbo
Re:Numbering (Score:1)
Almost, but not quite (Score:1)
For instance, people often wear sandals w/o socks. Many distance runners run without socks.
This is closer to "A house is better than a foundation." Yes, most houses do require cement or some such foundation (where the X server would be the foundation), but some homes can be used w/o that foundation, though they do not stand up nearly as well (a mobile home for instance, which could be compared to running a qt-based program under windows).
Re:personally (Score:1)
# cat >
foo
ctrl+d
smash (filesystems are for weenies
A couple of reasons... (Score:3)
_Also_ there's a swell idea called 'Xinerama' that is similar to multihead (id est, it still uses several monitors), but ALL as a single DISPLAY.
Want another xterm? Drag that man-page rxvt up to the third monitor so you can code in the tree xterms side-by-side.
- chad
The config file is particularly nicer to read and write, too.
In short, there's some nice new features, but only if you're itching to use them should you change versions.
Re:Numbering (Score:1)
Re:X development too closed (Score:4)
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Two words: network transparency (Score:4)
There are several extensions already present in XFree86 which do exactly what you're complaining about. The XDGA extension allows programs to bypass X and write directly to the hardware, and the XShm (or MIT-Shm) extention allows X and a program to share a segment in memory which the program writes to and X writes to the screen.
Your first argument also has nothing to do with XFree86, it's an argument against the X protocol. With the power of current systems, trading the network transparency provided by X for a small increase just seems dumb. You might be able to squeeze a bit more performance out of your P75, but you certainly wouldn't notice it on a PII 400. The one place it is logical to make this trade is with games. That's where the previously mentioned extensions come in.
On the other hand, I agree with you about the XFree86 developement model. X would certainly benefit from a more open developement model. Forking the tree would be a great way to piss off all the people who have been working for so long to provide a free (speech) X Server for us, but it would do little to make us a better X Server. A much better idea is to simply let them know we would like to see a more open development model.
Re:The license is a non-issue, good point still (Score:2)
Nah. I joined the team recently and have not seen anything that won't show up in a release later.
To be honnest I don't really know why the project is run this way. The reason that would make most sense to me is that this is related to meeting certain requirements of graphics board/chip manufacturers to get them to disclose information. There is a mad competition going on in that area and thus lot of paranoia.
A related reason could be that manufacturers fear bad reputation from betas not working well with their cards. I somewhat doubt that, because today in our community only bad specs give really bad reputation.
Of course there might be historic reasons for it as well. I remember vaguely some comments that the project had to put shields up when some external influence became too disturbing. Maybe some vet knows.
I would like XFree86 to open up more, if possible. Related projects like Mesa and glx have had a good result while being open. In fact the new DRI project has been placed on purpose outside of the XFree86 realm to allow more people to participate (I know several folks who don't work on XFree86 because of the closed nature).
The requirements for members are acceptable, so if that closedness is still required for dealing with the industry, another improvement to the present situation would be clear rules who can join and who can not, if such can be formulated. This would take away some arbitrariness from the brotherhood. :)
Re:What's the advantage? (Score:1)
Re:The license is a non-issue, good point still (Score:4)
But I disagree strongly that the forked system should be distributed under the GPL. I think starting projects is best done when licensed under the GPL, because it forces improvers to feed their improvements back into the community, and because it makes bigger step towards a free world. But I think once a project starts in a certain free license, it should stay there.
This is because although you can take BSD code, such as XFree86, and redistribute it as GPL, you CAN'T take GPLed code, even if it originated from BSD code, and redistribute it as BSD licensed code. This means that the XFree86 group will not be able to use the changes that the new project will apply to its own code.
I don't think that this is a nice thing to do -- the XFree86 have decided to allow this by choosing the BSD license (and I suppose they did either for ideological reasons or because they want their code to be used as widely as possible) but they HAVE contributed a lot of time and resources to create a free X implementation and we should not do anything to deny them of improvements based on their own code.
Secondly, if a GPLed fork would succeed, it would be able to use XFree86's code and ideas but not the other way round. Eventually it would pass the XFree86 and leave it unused. On the other hand, if the fork is under the BSD license both projects will be able to use one another's code and improvements and both will become much better as a result. Maybe one of them will become better than the other due to better design, and the other will be forgotten. Or maybe either will have its own advanteges and disadvanteges, and will be used depending on the user's specialized needs.
THIS is the kind of competition I would like to see, one that is more like the community I am a part of.
- Adi Stav
Re:The license is a non-issue, good point still (Score:2)
Do you know, that's possibly the worst logical fallacy I've heard all week? Unless you think you've demonstrated something actually wrong with XFree's current model.
Daniel
Re:What's the advantage? (Score:4)
3.9.17 is much more modular (Score:5)
Unlike XFree86 3.3.x where there are multiple X server binaries, each of
which drive different hardware, XFree86 3.9.17 has a single X server binary
(called XFree86). This binary can either have one or more video drivers
linked in statically, or, more usually, dynamically load the video drivers
and other modules that are needed.
and
The XFree86 X server has a built-in run-time loader, donated by Metro Link
http://www.metrolink.com [metrolink.com]. This loader can load normal object files and
libraries in most of the commonly used formats. Since the loader doesn't
rely on an operating system's native dynamic loader support, it works on
platforms that don't provide this feature, and makes it possible for the mod-
ules to be operating system independent (although not, of course, independent
of CPU architecture). This means that, for example, a module compiled on
Linux/x86 can be loaded by an X server running on Solaris/x86, or FreeBSD, or
even OS/2. One of the main benefits of this is that when modules are
updated, they don't need to be recompiled for each different operating sys-
tem.
This means the video drivers are standardized... Maybe this will encourage video card vendors to include an XFree86 driver along with the MS-Windows ones.
- Adi Stav
Re:What's the advantage? (Score:3)
1. Don't create backwards compatibility.
By doing this, customers have to upgrade because newer apps require the new X (or Windows). X doesn't do this. Windows has (3.11 -> 9x)
2. Create new file formats
MS does this every time they come out with a new version of Office. They don't do it for added functionality. They do it because they know exactly what will happen. Example:
Person A has Office 95. Person B has Office 95. Person B is Person A's customer, who frequently sends documents to person A.
Person B upgrades to Office 97. Person B is not that technical, and can't seem to figure out how to use "Save As" instead of "Save". So they send Word 97 documents to person A, who only has Word 95. Person A can't read the file.
Person A ends up buying the newer version simply so they don't seem outdated to their client, as well as so they don't have to make it hard (in their eyes) for their clients to send them data. The same goes for Excel and such.
As dumb as it sounds to computer literate people, this is a BIG THING in the non-techie world. I work for a very large insurance company, and we have to very strictly enforce software version guidelines to prevent hell breaking loose. If one department started using the next version before the rest, we would end up having to buy the new version if it was widespread enough. Why? Because:
a) Normal users are too stupid to use "Save As". And don't start preaching to me that they aren't stupid. They ARE.
b) The users who don't have the new version suddenly start whining about why they don't have the latest and greatest and why they have to go through all this trouble.
So yes, you CAN force somebody to upgrade. MS does it all the time, in order to give incentive for people to buy their new products. All it takes is a few people to buy it initially to cause havoc, and eventually everybody has to buy it.
Ever wonder why cars don't seem to last so long anymore like they did in way back when? It is for this same reason. Car manufacturers don't want a person to buy one car and not buy another for the next 15 or 20 years. They want people buying cars every 4 or 5 years, or sooner if possible. How do they do this? They intentionally engineer the cars to wear out just after the warranty. There are scientists devoted to finding the exact right materials with which to build car components so they last JUST beyond that 5 year warranty.
It is called Planned Obsolecense. (sp)
Re:X development too closed (Score:2)
XFree is not a 'closed' development, it's a controlled one. And it has to be controlled, as NDAs exist, like them or not.
-Posting at Score:2 just because it needs to be heard.
Re:Software announcement (Score:1)
treke
Did Slashdot just step sideways? (Score:5)
And these are the ones that got moderated UP?!
Look, first, if you don't like the way development is going, grab the source, and do it yourself. Don't necessarily fork the entire project, just take over your corner, and do whatever you like. Keep it in CVS, and merge the new releases in on a vendor branch.
Second, four letters: XSHM
Third, KDE is several layers above X, and requires X to run, so what the heck do you mean SMOKES?
Please, people, do try to pull it together, here.
Imminent demise of Slashdot predicted. Film at 11.
Someone didn't spend much time reading... (Score:5)
3D Direct Rendering
-Raw OpenGL compat Rendering Library -> Hardware
-GLX/DRI -> Kernel Module -> Hardware
-XLib -> X Transport -> X Server -> Hardware
X11 2D (Normal X)
-XLib -> X Transport -> X Server -> Hardware
3D Indirect Rendering
GXLib -> X Transport -> X server -> Hardware
XLib -> X Transport -> X Server -> Hardware
So while, yes 2D is done the same old way, There are many new 3D options available, including bare wire access to the hardware.
Two items on the NT video subsystem:
Note that one of NT's major sources of instabilities is in its video drivers. Any wrong call inside the driver can and does blue screen the box. With X's user-space model, this can't happen easily. There is a trade off on performance, but with X you get stability, multiple screens, and native network windowing, with the tradeoff being in having to use an asynchronous display instead of a synchronous display. (Displaying graphics synchronously gives faster graphics at the expense of CPU)
Also note that DRI is essentially an improved version of SGI's GLX implementation on Irix (SGI's version of Unix), which ABSOLUTELY SMOKES 3D rendering on NT, on neo-equivalent boxes. If you've never seen 3D done on a SGI O2 or better, you haven't seen good 3D. X isn't such a dog then...
jf
Re:X development too closed (Score:4)
Yup. Often it's me. I'm happy to see people are beating me to it now.
You know what? Shut up.
Let me think.. No.
But you have a nice day, too, OK?
I have one word for you and it is NDA.
Damn, that means I need two words to one-up you:
Modular programming.
You remember, that non-monolithic X Server design which is one of the biggest improvements in XFree86 4.0? If you've still got a reason why we shouldn't have, say, anonymous CVS access to the X server core and all the non-NDA drivers, then I'd like to hear it.
It's not *HARD* to become a developer, and anyone who complains about it being 'too closed' has obviously not even looked INTO the subject.
You don't seem to get it. I don't want to become a developer just so I can figure out why XFree86 has mouse input bugs on my machine and hardware cursor bugs on my girlfriend's. Another poster who wanted to work on Truetype support years ago didn't want to sign up to "be a developer" before he could even read a mailing list archive and see what was being worked on.
How many people currently doing the heavy work on the Linux kernel started by saying, "You know, I want to become a full-time Linux developer?" I'd like to see numbers, but I'll bet it's not nearly as many as those who started by saying, "I wonder if there's a driver in development for my foo card,", or "This discussion of the unified page cache on linux-kernel is interesting, I think I'll pull down last week's devel source and see how it works.", or even "This looks like a bug. I think I'll check the latest source and see if it's being fixed."
XFree is not a 'closed' development, it's a controlled one.
Linux and FreeBSD are both controlled, but we get frequent releases (and more frequent prereleases) with the former, and anonymous CVS access with the latter.
And it has to be controlled, as NDAs exist, like them or not.
Needless to say, I don't. But this is a red herring; nobody said we wanted up-to-date source code on NDA'd drivers, just on the 99% of XFree86 that is free software.
To be fair to the XFree86 developers, the 4.0 pre-releases are coming more frequently than they have in the past... but the situation still isn't as good as it should be. To be more fair to the XFree86 developers, I'll point out I think it's a shame that they are underappreciated, even as they write a successful free software project that is arguably as complicated as and more important than the Linux kernel.
However, if they want more developers, they're not making enough of an effort to have a project that is open enough to be attractive to tenatively interested programmers.
And they do want more developers. They're asking for them strenuously enough on the web page. What was the initial timeline I heard last year, XFree86 4.0 by June? That's not quite a 100% slip from schedule, but it's close.
And I want them to have more developers! Between the complaints about configuring X, the emergence of DRI 3D and real GLX support, and the major architecture changes in 4.0, they've got one of the most important free software projects in existance on their hands, and I'd like to see them have every hand they can get.
Eric Raymond always uses gcc vs. egcs and FreeBSD vs. Linux to show how even among free software, projects which are "more open" than others tend to be more successful in the long run. I don't think it's worth a code fork to find out, but it's a shame there isn't anything competing with XFree86 to provide a third example.
First impressions (Score:2)
Now for the results. The only tweaking that had to be done to the source tree was to remove the doc directory from the build process. Looks like the top Makefile is missing in the docs directory. After that things compiled just fine (Debian Potato BTW).
I had to do some massive editting in the XF86Config file to get things up and running on a G400. I don't understand why I have to specify the location of my card on the PCI bus. Can't XFree figure this out automatically?
Anyway, this thing is SUPER MODULAR, I like it! I had to add the xaa module in the module section in order to get full XAA (duh) accelleration and to remove the unresolved symbols reports from mga_drv.o. But now that it works --> Mozilla is bloody fast!! Slashdot renders in 2 seconds, and that includes the time for the data to download! I'm using Mozilla because the netscape binaries either segfault or act up under 3.9.17. Next on my list of most wanted features: GLX MGA support!
Perhaps more info later on...
Re:X development too closed (Score:2)
I guess the point is, you catch more ants with honey...
-----------
"You can't shake the Devil's hand and say you're only kidding."
X: Satan's Window to the World (Score:4)
It is no coincidence that the windowing system is named X. Study after study has shown that the sociopaths who use Linux and other Linux-like operating systems primarily use their graphical environments to view pornography. Fitting, isn't it? A piece of software named X that is used for viewing X-rated material. An independent study performed by the beloved Reverend Jerry Falwell has revealed that there is an abundance of homosexual pornography on the Internet as well. Evidence of this can be found by looking at the Reverend's IE 5.0 bookmarks.
Friends, here is what we're dealing with: a windowing system for a communist operating system that is used for the most part to view pornography of a homosexual nature. I've just clicked off so many negative things that I'm quite convinced that we all see why it is so important that X be destroyed. You see, I believe that X is Satan's window into this world, his eyes and ears in the world of the living, where he gets a chance to sink his claws into unsuspecting prey and secure their place in the land of the damned when they move from this life to the next.
XFree86 is doubly bad, because it also happens to be free software; as we all know, free software is a concept that is universally despised by God's good little capitalists. It's not surprising that it's free. Satan wants it to be free. He's dumping it onto the world and encouraging its use by giving it an attractive price. Friends, we all know that monetarily, XFree86 has no price
So what can we do to stop X, with its promotion of homosexual pornography, and its augmentation of the intrusion of the socialist Linux operating system into the lives of decent people? Friends, we can do a lot. Write your congressman (I do not say "congressperson", because it is universally known that women cannot be effective legislators) and tell him to support the XFree86 Supression Act being introduced next session by the wonderful American Bob Barr. If you happen to have access to any Linux machines owned by friends, reformat the drives and install Windows 2000. Burn their Linux CDs, if you are so inclined.
Friends, I am convinced that we have the moral fortitude to fight this fight and emerge victorious. We will meet X head-on and defeat it in a glorious battle for the minds of our children. X will not win. X is going down.
Thank you for your time.
Re:vendors won't be interested (Score:4)
the question is whether the cpu-dependancies are just an issue of endianness and bits-per-word or what, as if so, perhaps a post-processor could be developed that reverse-compiled them, and then recompiled them for a new platform... not much in the way of hardware secrets is given away by changing the endianness of bytes....
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
Re:X development too closed (Score:2)
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
Re:Yes, time to fork. (Score:2)
I like GPL, but X is traditionally under the X license (basically BSD w/o adverizing clause)
this is why most windowmanagers are under the X license... they could go GPL at any time, but most respect the wishes of the XFree folks (and the X consortium folks above them...)
just because it is legal doesn't mean we should do it, and oh, BTW, forking X is a HORRIBLE idea... something that complex should not start having compatibility issues!
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
Rather, promote those who excel in the community (Score:2)
I think it's important for companies to follow published standards. If the product follows a published standard, then at least minimal drivers could be produced without much effort - heck, one day we could have an OS that comes with the "standardized" driver code and then companies could release enhancement drivers. On the other hand, I personally don't like the idea of a "compatability list". I think it limits the vision of people writing new stuff. We need a "not-yet-compatable" list. ;)
Re:What's the advantage? (Score:2)
people can choose not to upgrade to close source as well, leaving the only difference being the fork...
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
Re:KDE (Score:2)
Actually, it's more like comparing the apple to the apple tree.
Re:Yes, time to fork. (Score:5)
The FSF advises against it. See The X Windows Trap [gnu.org]. I quote:
So if even RMS advises against GPLing the X Windows System then it is probably not a good idea
Re:X: Satan's Window to the World (Score:2)
Internet Explorer has Favorites. There are no Bookmarks in Internet Explorer.
Or did I miss the entire point of the post?
Re:nVida geforce and X (Score:2)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:What's the advantage? (Score:2)
Hmm.. Jave Video driver :). (Score:2)
I.e. It can be done but it's probably be slow. Better to make X source compatible across CPUs so the PPC, x86, Alpha etc... bins are separated by simply a "make all"
Have my GeForce running on 3.3.5 (Score:2)
About 2 weeks ago a patch for the SVGA server has been availabe to add support for the GeForce. You can get the precompiled binary, or patch of the SVGA server at http://www.s2.org/~jpaana/nv/ [s2.org]
I haven't had any problems with it, plus support for the GeForce is going to be availabe in 3.3.6 - which should be availabe soon.
Real nice but it needs improvement. (Score:2)
I have a couple of questions related to this
1. Does anyone make any decent video cards (actually new things) that would run on classic PC hardware say something that would be found on a "regular" computer on a 486/33 or 486/66 motherboard
2. If not why not
3. Is there ongoing development in creating either a modular windowing system or something lightweight (similar to Qnx or similar). Most of my hard crashes in Linux are usually due to running graphical apps that take almost all the system resources and then make the system totally unresponsive to even direct calls to the X server.
4. Something that would allow for better setting of parameters or perhaps autodetection for various modes a little better.
I tried to set up my videocard a few times before I got anything that would work. First video: Super-VGA;Chipset: ATI 68800-6 (Port Probed);Memory: 1024 Kbytes;
RAMDAC: Sierra SC1148{2,3,4} 15-bit or SC1148{5,7,9} 15/16-bit HiColor (with 6-bit wide lookup tables (or in 6-bit mode));Attached graphics coprocessor:Chipset: ATI Mach32 Memory: 1024 Kbytes
I got the above when I attempted to superprobe it so I was at least able to run the Super VGA server but when I attempted to run the Mach32 server the screen was extremely elongonigated or it allowed for a high resolution but when I ran something like a window manager or an application all of the little details like the menus and buttons and such were just eliminated with their text. Now not to create something that may be a source of shame but does anyone still care about this type of thing anymore or is this release and the up comming one just going to be a little thing for all the big boys to play with around town with their brand new $7,000 graphics adapters. I think that the server may increase preformance but I'll be damned if I can get the thing to adaquately work.
Re:This is a broken design. (Score:2)
Your X client sends the message: "draw the string 'I am a lamer who doesn't understand X' at (26, 44)" and the X server then proceeds to spit each and every pixel that makes up the string over the AGP bus. Depending on the font size and average coverage, the amount of AGP bandwidth used will vary, but even in the simplest realistic cases, the X protocol will end up using ~25-50x less bandwidth than pushing the pixels directly, and in typical cases, X will be well over 100x more efficient (This is all ignoring things like LBX which help even more). An X server has a much more complex and high level command set than even the most expensive professional graphics accelerator.
Your argument does, however, apply to protocols like VNC. That doesn't, however, make VNC any less useful for the people who use it.
Re:X development too closed (Score:2)
There are companies out there that have been quite supportive of XFree86. They should be rewarded. There are enough of these hardware manufactures that there's no need for a Linux user to ever buy anything else. So why not encourage people explicitly to buy from friendly, open companies?
And there's some companies that have been doing the right thing for a long time, and have documented their hardware for a long time, and have been very helpful in bringing Linux to where it is now. Being so focused on the future that you don't remember who your friends are doesn't help make friends.
Right now all the information about who's been good to Linux comes from a few remarks I've heard here and there, and a vague memory of what used to be supported a while back. I would like to know what manufacturers have had a history with Linux (including XFree86), and have been helpful providing drivers, documentation, and monitary support. I know such a list would make a big different in my buying habits. I know such things make a big difference in the quality of the drivers, and good hardware without good drivers is useless.
Posting of software updates (Score:2)
Instead of simply providing a link to an FTP site containing the updated files, how about offering a link to the homepage, or some sort of "announcement" or "new features" page on the web-site. That way we can, at a real-quick glance, see what's new and decide if it's worth it before starting a download. It'd also save some time hunting down the relevant information manually, or, -god forbid-, via another site like Freshmeat...
(as for the previous poster's comment about a software-update posting being irrelevant on Slashdot, keep in mind that a large portion of the Linux community uses XFree86, plus it's bleeding-edge... so it's "News for Nerds" and "Stuff that Matters"...)
Daltorak
Re:X development too closed (Score:2)
I think not just some, but a LOT of companies are more than likely to respond to being blacklisted by saying "Yeah, who needs 'em. Bunch of pseudointelectual tightwads anyway. The real money is in Windows."
And they'd be basicly right.
I don't mean this to be a flame, it's just, the least effective way to get someone to agree with you is to tell them you're really angry at them and want to take your ball and go home now.
Getting really ticked off at people and letting them know it never generated much progress in the past, don't see why it would in the future. Think about it.
Re:3.9.17 is much more modular (Score:2)
Kernel traffic [linuxcare.com] / the linux kernel mailing list makes some intresting points about binary drivers.
From my point of view, binary == good as we get drivers quicker but if the driver as a anoying flaw there is very little that can be done about it (with out reinventing the wheel).
Re:X development too closed (Score:2)
As long as any company can make small offerings, irregardless of what they've done (or not done) before, and then get lots of good press, we're not doing ourselves service. The late comers get better publicity than small but consistently helpful hardware manufacturers.
All this Internet investment place Linux in a situation where it could manipulate others or get manipulated. The long bet has payed off big for some, and companies are looking for the next long bet. We can use that. But as long as we approach these hardware manufacturer begging they will see us only as beggars.
Re:The license is a non-issue, good point still (Score:2)
Re:What's the advantage? (Score:2)
The difference between OSS and proprietary code is that commercial developers have a strong financial incentive to break file compatibility in new releases, thus encouraging existing users to pay for an upgrade. Historically, this hasn't been the case for OSS applications - if anything, the incentive has been to make OSS upgrades unnecessary unless the user has a need for the new features, thus reducing support questions to the developer who, after all, is doing this for fun and doesn't want to spend endless hours providing support for users who have upgraded and now can't use their old data.
I say "historically", because there's a danger that this may change now that companies which embrace OSS are expecting to make money from support. An easy way to ensure a steady flow of lucrative support calls is to produce a new version of an app which is incompatible with previous versions' data files. Let people donwload the new version for free and then charge them for the tech support when their old data doesn't work anymore. Ok, that's maybe a bit too cynical a view, but it'll be interesting to see how good version compatibility is in the OSS apps which are commercially sponsored.
Minimal Properties of a Replacement (Score:4)
Only idiots compare Berlin to X, as the systems have very little functionality in common. X knows how to talk to hardware, whereas Berlin doesn't. Berlin needs to have some combination of GGI and OpenGL.
It would be vastly more sensible to compare Berlin to GTK, Qt, or FLTK, as that is where there might be properties in common.
It needs to run on many kinds of systems.
GGI would be the most likely candidate for this; it's not there yet.
Yes, there are users that only want to run applications on one host's console. And that's why X provides things like the SHM extension so that if everything's local, performance can be made better.
But those that focus on Console! Console! Console! are ignoring that they're not the only users, they're restricting flexibility, and, more importantly, they're ignoring that network support is getting more important all the time. You see, there's this newfangled "Internet" thing...
"GnotX" won't represent a realistic alternative unless it is network-aware.
If the new system doesn't permit running the applications that we already have, then this means discarding all of the X-based software that people have been finding useful over the last dozen years.
Notably, no more KDE, no more GNOME, no more StarOffice, no more WordPerfect, no more ApplixWare, no more Netscape.
Even if there was a way that "GnotX" made a GTK, and thereby GNOME, port easy, this would definitely be injurious to vendors of X software like ApplixWare and WordPerfect (that have some Motif involvement, and thus mandate having a real good X emulation).
"Legacy" vendors won't see this as a move to cooperate with, and like it or not, that's a factor having significance.
People propose things as replacements for X that weren't truly designed as such, or that, worse still, aren't really designed at all.
The original incarnation of "Berlin" amounted to this; they flung epithets at X, claiming it was obsolete, and that they'd do K001 x86 assembly hacking to produce something that would just destroy X.
This was quite silly; they never had a clear design, only a set of claims that amounted to "Because We're Cool Hackers, We'll Outdo X." That may represent intent; that does not represent design.
Video card independance! (Score:2)
Why should console apps act differently than X apps when it comes to 2D/3D graphics acceleration?
If I wanted to create a GUI system independant of X I would not get the benefits of X's video card drivers. I would have to reinvent the wheel. I find that extremely limiting as more and more companies come on to the Linux/Unix bandwagon.
BTW this will never happen but one can dream.
Re:X development too closed (Score:2)
Linux users are a small percentage, we don't yet have the power. Microsoft boycotts a company, the company suffers, linux boycotts a company, maybe a 1% loss?
Something else to realize: the majority of linux boxes out there are servers...they don't use the latest and greatest video cards (do I REALLY need a GeForce256 in my mail server?)
Boycotting a company now would just give them resentment of linux. Resentment turns to anti-linuxism, whichs turns to more "friends of microsoft"
Re:X development too closed (Score:2)
I do occasionally fix bugs in other people's Open Source software, but not as a "serious" developer. Rather, I download the latest source, see if it fixes my problem, and patch it if it doesn't (and send the patches to the originator). I don't bother trying to fix the source for the "released" version of the program, because it is a duplication of effort if somebody else has already fixed that problem in the latest source, and I do NOT beta-test software that I do not have source code to -- I want to be able to pop it into gdb and do a stack trace if it core dumps, and be able to send a patch as well as a bug report to the author.
Not that I beta test things very often. Usually it's on a whim. E.g., I downloaded the KDE 2.0 betas (1.8?) and compiled them with debugging on, simply because I was feeling frisky one Saturday afternoon. I tried it out, said "hmm, nice, we'll see what happens when the rest of the KDE programs are ported to this", and went back to KDE 1.2. But the point is that, by not requiring me to jump through hoops, this was one more eye that looked at the program. Not a seriously deep look, mind you -- I did not (and do not) have time to be a serious beta tester -- but still, eyes are eyes.
I understand the problems that the XFree86 team faces insofar as NDA's are concerned. After all, the whole reason for forming XFree86 Inc. was to have a corporate entity that could sign NDA's with video card manufacturers. But I am telling you that this IS a reason why the XFree86 project has trouble attracting developers -- the situation adds a hoop to jump through for someone like me, who doesn't have time to be a "serious" developer. Not a seriously high hoop, but hey, I'm not being paid to develop XFree86, y'know, and any barrier at all to participation is too high a barrier for someone who wants to make an occasional casual contribution. I don't have any facile solution to the problem, certainly nothing as simplistic and moronic as "fork the project!" or "boycott NDA-requiring video card makers!". But to deny that it is a problem is to deny reality.
-E
Re:X development too closed (Score:2)
Ok, done? Here's a clue: 4.0 isn't finished yet so it's not modular yet so they can't release the code as the NDA parts aren't (probably) completely separate yet.
Why don't you just join the XFree86 team and then work toward having 4.x's all more open?
Overhead of socket calls vs. direct calls (Score:2)
In addition to reducing fundamental stability, the Windows solution also makes it hard to release resources when a thread or process dies. Windows leaks memory like a seive, whereas all "X" resources are tagged and when the OS sends a SIGPIPE to the "X" server to signal that a socket has closed, "X" can release all resources associated with that socket.
BTW, if you are running the "X" server local to the machine, the socket can be used only for control commands, not for actual data. Actual data would be sent via shared memory. I suggest that you read up on the SysV IPC spec and see why it's not a good idea to send *ALL* data to the video display via shared memory (basically: shared memory does not go away when the process that allocated it dies, and the "X" server would not be notified if that other process died so it wouldn't know to manually de-allocate that shared memory).
Finally, regarding the performance argument: SGI. I think that says it all. SGI has graphics performance unmatched by anyone -- and runs "X". SGI is perfect proof that "X" does NOT have to be slow -- if "X" is slow, that's an implementation problem, not a fundamental problem with "X". Yes, it's faster to draw directly into a frame buffer than it is to draw directly into a shared memory buffer and then send a command via the "X" socket -- but not MUCH faster, especially if (as with SGI) you have made some optimizations at the OS level for local sockets. I think they have it down to where sending data on a local socket is actually putting it into a buffer, and then mapping that buffer into memory on the other end, somewhere around 20 or 30 cycles. The only real time consumer is marshalling and de-marshalling (i.e., converting the data to a stream, then converting it back to native-format binary at the other end), but that's hardly a killer.
-E
No need to comb your hair... (Score:2)
(Criminy, some people would need a prybar to haul their twisted knickers out of their arses!) Don't be so uptight -- laugh once in a while!
J
Re:RedHat and others (Score:2)
_E
Re:X development too closed (Score:2)
The snapshots are already broken into the "main" portion of the X sever and the driver modules, i.e. there is a binary that starts up, loads the config file, loads in the appropriate module for the particular graphics card family, handles the input devices (which are also modules that can be dropped in place without recompiling the X server), and then does all the back-end work like networking, communication, image setup, etc. It then just passes the actual images to the video driver to display. The drivers are all separate from the server itself, and can be programmed independantly, compiled separately, and then dropped into place. Sound familiar? That's just how the kernel works. All the hardware drivers are modular and can be loaded/unloaded at will. There are people all over the world who are not full-time "kernel developers" who simple have an itch, pull up the source to the driver for their particular peice of hardware, maybe come up with a patch or two, and email it to the appropriate maintainer. If it works, and is good enough, it gets into the next release; if not, it gets canned or modified. This is exactly the model that Xfree should go toward (and I think/hope/expect they will shortly after the 4.0 release)
The various modules for video, keyboard, mouse, touchpad, etc. can now all be developed separately, so that one doesn't (shouldn't is more accurate ATM) have to sign an NDA to be in on the development of the core functionality and design. Those who have the time, expertise, and interest in working on the FooX128Ultra(TM) chipset support can sign that NDA and start coding, while us regular mortals can just browse the up-to-the-minute anonymous CVS tree and see where we might want to chip in, or monitor the mailing list (read-only maybe, allow the "full developers" posting priviledges or something) to see if maybe there are areas we might be interested in, or a call for some "grunt work" like documentation or something else that even non-programmers could do.
Anyway, I just want to put aside the debate for a moment to say that, without a doubt, multihead and Xinerama ROCK ASS (with petrified hot grits, no less!) that was just to be humorous, don't confuse me with the lame-ass firstpost/grits/petrified-and-naked people)
Portability of protocol (Score:2)
That could be compared to HTTP, where there are an extremely diverse set of web servers, resulting from its relative simplicity.
As for the size of X, I understand that the port to the Itsy weighed in at about 300K. The things in X that are bloated are things like:
- Font cacheing and the simple fact that scaled fonts eat RAM
- Cacheing of hidden objects/windows
which represent things that would cause similar "bloat" in any alternative system.Missing (I)makefile... (Score:2)
WAY TO GO XF86 DEVELOPERS!
-- iCEBaLM
Re:Missing (I)makefile... (Score:2)
Just make an Imakefile with nothing in it.
... And you'd still get the same "no rule to make clean [error 1]" on its initial make clean pass.
I'm lame? Maybe you should check it out first before posting?
Interestingly enough, the
-- iCEBaLM
Re:X development too closed -- Not the DRI (Score:2)
We hope to make it as open a development process as possible. I'm the intermediary between XFree and the SourceForge project. I take the public snapshots and move them into SourceForge, then I do all my work on the public site, and finally I send patches back to XFree. It seems like the best way to do open development with the current restrictions. I does add a little overhead for me of course!
So, if you're interested in DRI work, please check out our SourceForge project. We are looking for anyone interested in participating.
- |Daryll
Re:G200/G400 (Score:2)
What needs to happen is for the "utah-glx" drivers to be moved to the DRI framework for use under 4.0. We've created a public open development site at http://dri.sourceforge.net [sourceforge.net] for anyone who wants to work on the DRI.
- |Daryll
Re:DRI? (Score:2)
The DRI work is actually being done in an open repository at http://dri.sourceforge.net [sourceforge.net]. I encourage anyone interested to check out the materials there and join the development list.
At the moment, it is probably only ready for developers (rather than end users), but we're making good progress.
I incorporate all the public XFree snapshots into the SourceForge site, do all my work on SourceForge, and then feed patches back to XFree.
- |Daryll