Slashdot Mirror
XFree86 4.0.2 Released
XFree86 4.0.2 is officially
out now. Besides adding a driver for those us with S3 Savage chipset based laptops, support for a variety of other chipsets, mesa updates,
improved DRI support, this new release adds the Render extension which
will hopefully give us anti-aliased fonts, alphablended menus, and a stromboli delivered nice and hot to your door. Mmm. Strom.
A growing number of the cool new features in XFree86 seem to really be Linux only. Granted, that's where the users are and that's where the money is, but it's a shame that XFree86 is becoming less of an X server for free OSs and more of an X server for Linux.
For example, is there any DRI support for non-Linux platforms, especially *BSD?
What about USB support?
What about support for the newer PCI features/configuration knobs?
According to SGI, GL means Graphics Library, and not Graphics Language. Besides, what language would that be?
You may only want to have some fonts antialiased some of the times, the way it is implemented with render gives more flexibility and more interesting features like alpha transparency
You Like Science?
You Like Science?
You Like bottomquark.
They seem pretty hesitant to talk about it, even in the unofficial nvidia irc channel. That's the _first_ place it'll probably be available though.
/ctcp ice-dcc xdcc list
:)
:(
irc.openprojects.net, #nvidia
Be sure to bother ripperda if he's on - he works at nvidia doing coding for their linux drivers, and just loves to be bothered!
I find myself on there quite often to see if they've improved VIA chipset support, which currently sends my kernel down in a blazing fire
--
--
grep "xercist"
The reason you're seeing such delays at startup is because Gnome and KDE are huge, versus the X4 server which starts very quickly. I run X 4.0.1 with the latest and great version of WindowMaker, and startup from the time I type 'startx' to the time it's finished loading is under 5 seconds on a PIII-550. Needless to say TWM and others less intensive (Blackbox is great) start up even faster. Try just running 'X' if you don't believe me, and you'll get the standard gray screen in about 2 seconds. A lot of time the X server might start up slowly if it can't reverse resolve itself for whatever reason, so make sure your own machine is in /etc/hosts.
Interested in open source engine management for your Subaru?
Is there any text that explains the new XFree 4 infrastructure in plain english?
you've got:
DRI,
GL, GLU, GLUT, GLX,
Mesa,
Utah GLX,
SDL...
I know very little about X/video rendering, but I'd like to upgrade to XFree4 and actually know what pieces of the puzzle i need.
Does DRI replace Mesa? Does Utah GLX replace DRI for cards it supports? Is Mesa even needed? Is plain Mesa included in the Xfree source tree, or is it a fork? If I don't have a 3d card, does mesa still install as a software renderer? Does this give better performace over the 1fps syndrome in xfree3/windows95? Are any of the projects I named obsoluted by the new infrastructure? (utah glx comes to mind...)
maybe someone here can explain it on a level somewhere in between the "gimme URLs of the RPMs so i can upgrade my redhat box" and the in-depth developer documentation on the dri/utah glx pages.
Hopefully any responce would also give others the confidence to take on this new infrastructure.
Also, does the new "render" extention take effect automatically for all new programs compiled that link to the standard libraries?
Look at the new features! If this were MS code, it would be worth at least a century or two jump in the version number! The cool ones are:
Bug fixes: Yea, those.
Render Extension: The render extensions and additional stuff added to x11perf, xft, and xlib to support it.
Compositing code for Render is complete, but a lot of stuff (polygons, image scaling, seperate alpha, see the summery) are still unimplemented.
Updates to nv for GeForce2: Hah! BeOS had GeForce2 support before X!
xf86cfg: A new, graphical configuration utility.
And much much more!
Here is the link.
It says that Render uses XAA for acceleration, and acceleration on the MGA chip is already implemented. 2Qs
1) If it uses XAA, why does it only accelerate on MGA?
2) Does this mean that it becomes a Render vs 3D choice for NVIDIA users? As far as I can see, the NVIDIA drivers don't support the Render extensions. Or am I just confused.
A deep unwavering belief is a sure sign you're missing something...
I feel it is inexcusable that they did not hack the existing font mechanism to do antialiased fonts. I want to point out that the much derided MicroSoft managed to add antialiasing to their existing rendering system without requireing the use of new interfaces.
Yes, adding a new and nicer interface is necessary, but they should have made the old interface, which is what existing programs use, work as nice as possible. The fact is that we are not going to see antialiased fonts on the screen for a LONG time even now, because they did not do this.
The XFree86 pieces are easy to do if FreeType2 is already installed; I expect the distro vendors to just make X require FreeType2 and ship a package for that as well.
I know at least one Linux vendor will.
Great reply... I wish slashdot had a feature that allowed people to (+1, Thanks) replies to their comments. Doesn't seem very abusable...
Thanks for that info...stuff like
"You can think of SDL as a more powerful version of GLUT."
is info not mentioned on the projects page, but for mortal users, greatly helps to visualize the part each plays. Sure, it may be a bit over simplified, or only 99% accurate, but for curious users just trying to understand the system without reading the source, it's a big help.
One followup question...in Xfree4, if you have DRI working, is all 3d rendering through Mesa done as direct rendering? Windowed and fullscreen? I seem to remember only some applications actually could/would use the DRI. http://dri.sourceforge.net/components.jpg shows a "DRI module" in XFree and the Kernel, under the 2d and indirect rendering, which seems a bit off...
I'm also glad to hear Xfree4 uses the whole Mesa base... I had the impression before it was mostly replaced. I had a lot of trouble installing Mesa and the glide crud in xfree3, this new system actually sounds pretty simple for the user, which is great news.
Thanks again!
So how much of Render has actually been implemented. Is the transparent menus in twm stuff there?
--
enterfornone - logging in for a change
The "can't allocate colors" argument is also bullshit. I do not expect antialiased fonts to work without a TrueColor visual anyway, so there is no colormap to worry about!
The Xlib interface is entirely designed to be the same level as the Windows GDI. There is a 1:1 correspondence between the calls in many cases! (Windows copied lots of it, you know). The fact is that X botched the way to specifiy the fonts, so any practical interface requires an enormous and inefficient toolkit that has to enumerate every font on the server to find the correct one (this needs serious fixing with a new font-selection interface). However once you have selected the font you can use the drawing code in Xlib quite easily, without any toolkit wrapper.
Just quit with the lame excuses, and admit that the internal code is such a horrid mess that nobody in 10 years or so has been able to change it to non-binary!
Can you point to some documentation for Xft?
Does it do any kind of sharing when a few dozen applications all try to draw the same font? Perhaps this is not necessary nowadays? However this seems to be the obvious reason to put the fonts in the server.
If the X server does not have the render extension, can Xft work at all (even producing very bad output) or does it just abort? Unfortunately I think you better do something about old X servers, otherwise all the applications will do their own kludge, or worse it may discourage use of Xft at all.
Is there a *SIMPLE* font-naming scheme. By "simple" I mean that if I say "Helvetica" I get a font, ALWAYS! It is far, far, far more important that I get a font, and it be the same one every time, than that it actually be the sans-serif font "helvetica". Any scheme where the font names are not user-friendly will make applications and toolkit make their own translation from user-friendly to system names, and they will probably be incompatable with each other. Notice that it is ok to also support "complex" names that specify fonts exactly, as long as simple names are accepted. Also, ALWAYS return a font, no matter what garbage name is thrown at you, you can report an error, but make the best guess anyway.
Can you do anything about UTF-8? It would help a lot if there was a way to render raw UTF-8 strings (and 16 bit unicode while you are at it), and all characters show up. Best answer is to have a 16/8x16 bitmap font containing the entire Unicode set, and any missing letter from a font pulls if from there (clip and center it, don't scale except by integers).
Please draw something, even a box, for every single code. I recommend small "^A" for the control characters.
Draw the MicroSoft "extension" characters for the range 0x80-0xA0. Don't pretend that this is not a standard. It is and there is nothing we can do about it.
Ah. Typical /. iDot. NVIDIA has "a clue."
.x releases, much less .0.x ones.
A) They can't because some of the stuff is proprietory code.
B) They can't because an ICD isn't just a driver, its a whole freaking OpenGL ICD. OpenGL ICDs are expensive and time consuming to develop, and every other consumer manufacturer is having troube with theirs. Given the fact that NVIDIA's ICD is totally kick ass, why would they give chip makers like ATI an advantage? I'd wager that if ATI's drivers were as good as NVIDIA's, then the Radeon would be at least 20-30% faster. Also, the Matrox G400MAX would have put a serious dent in RivaTNT2 Ultra sales had NVIDIA's ICD been open. Ideally, what NVIDIA would do is split the drive into three parts. An OSS kernel driver, and OSS X driver, and a closed OpenGL driver. That way they could keep the code closed, yet be able to implement extensions like this. Also, I don't think they really planned on this. Who thought that 4.0.2 would include such a innovative component? Stuff like this just dosn't get added in
C) They're a business. Get over it. Right now, you taking your Viper 550 out and putting it in our router probably costs them less than giving ATI free code.
D) Whining and insulting is no way to get what you want. That's why people consider the OSS market a dangerous proposition. If you want OSS drivers ask nicely, help them through it. It is a totally new paradigm, and its benifets to them (if indeed OSS has any benefits to them) will need some time to digest.
A deep unwavering belief is a sure sign you're missing something...
- Qt changes available here.
- Gtk changes in process.
- twm hacks should never see the light of day.
Does that mean they're in this release? Or not?The X11 protocol and Xlib are not at the level of abstraction of the Windows GDI, Postscript, or other, similar APIs; they are lower level. Anybody dealing with them needs to write a lot of code dealing with different device classes. In X11, you get a Windows GDI-like API, with all its conveniences and limitations, more at the level of the toolkits. Such toolkits can then provide you with antialiased rendering when available without code changes. GTK, Qt, fltk, and wxWindows all have hooks for putting this functionality in.
He is probably complaining that the page is readable, unlike most web pages created after 1996. Or maybe he have configured his browser to make pages unreadable by default, and is complaining that this page doesn't overwrite his settings.
XFree just keeps getting better and simplier to config (xf86cfg is great for the first version) and in particlar many thanks to Keith Packard for the wonder render
Nevermind xf86cfg, have you tried "X -configure"? Spits out a usable X configuration file. You then just make whatever changes you want to it.
Just had a look at that, nice. xf86cfg seems to just be based on the same idea but graphical. X -configure would have been easier as all I wanted was a working config. You know, one thing I've noticed is that X has certainly got a lot easier to configure. I remember configuring X a couple of years and trying to dig out mode lines was a nightmare. My config file is a quater of the size it was back then. Things are moving in the right direction at least.
A journey of a thousand miles starts with a brutal anal raping at airport security
AFAIK:
Glide is not an X issue. XFree86 4 only provides an OpenGL-compatible interface (using Mesa), which has drivers for specific hardware (such as 3dfx chipsets).
Glide drivers go around X and direct to the hardware, so are supported (or not) by 3dfx.
You can go poke around the 3dfx site (does it still exist?) Or 3dfxgamers, looking for linux stuff, although I doubt you'll find anything official for glide under XFree86 4 -- I think glide was officially deprecated by the 3dfx crew (and, of course, 3dfx has gone the way of the dodo).
However, the glide was released via open source, so someone might have done something with it.
Sorry I can't be more help.
Has anyone heard anything from Nvidia about when they will release new 'nvidia' drivers (not the 'nv' drivers) that will support the new render extensions? It's a shame they're not open so the X people couldn't add it themselves, but the 'nvidia' driver is much faster than the Xfree86 one.
;)
I really hope they get something out soon, because I'm just itching for readable fonts in X via my Geforce2 MX!
On an unrelated note, did anyone see this on the release notes? :
- Qt changes available here.
- Gtk changes in process.
- twm hacks should never see the light of day.
Classic
I'm sure that if you ever went on a userboard and asked, you'd get tons of people trying to help. (Be users groups are very friendly.) However, that's a moot point. If you don't like it don't use it. If it doesn't support your hardware, then certainly don't use it. If you are into programming, and want to help out, then go ahead to BeUnited and join a project. If you're starting a programming project, and you want cross platform support, then program with non-X OSs in mind. (Use Qt or GTK or something cross-platform.)
A deep unwavering belief is a sure sign you're missing something...
Those "fucks" don't support the D-Link 530TX for the same reason those "fucks" at XFree86 aren't doing DRI drivers for the Sis630. Limit time, limited resources, limited demand.
And those "fucks" have greast SBLive! support. If you have a particular problem, just ask for help.
A deep unwavering belief is a sure sign you're missing something...
If it were automated, (eg. pusing the reject-already submitted button gives you a certain messege) takes no time at all. And unless the guys going through the messeges aren't doing what we think they're doing (randomly posting messegse, which would account for many of the errors made recently) pushing an extra button really wouldn't increase the time factor.
A deep unwavering belief is a sure sign you're missing something...
That explains why nobody codes directly to xlib. And to tell the truth, the X protocol is just a dumb idea. Yes, you heard it here first (NOT) There is a reason for having some abstraction at the lowest levels: it allows apps to take automatic advantage of new features. The idea of putting a half-finished windowing environment (X) on top of UNIX is the whole reason you have mismatched applications, non-uniform configurations (wouldn't it be great if X display configs would work for every application?) and all the other problems X has. The sheer fact that every other windowing system has the sense to include some layer of abstractions for apps to code to should give you an idea that the X designers are alone in their thinking that a windowing system should implement *no* user-level features.
I would really enjoy it if XRender were as good as it hast he capability to be. Of course, now I know exactly what is going to happen. I'm going to be staring at Netscape's un-anti-aliased fonts until v7, XplayMidi will never give me anti-aliased fonts, and I'm going to have to eventually deal with 3 different config formats for my anti-aliased truetype fonts. (one for each toolkit)
A deep unwavering belief is a sure sign you're missing something...
I serious doubt you want only your Qt fonts anti-aliased and your Motif fonts un-anti-aliased. If it were lower than the toolkit level, you could have a config program that specified whether you wanted anti-aliasing or not.
A deep unwavering belief is a sure sign you're missing something...
Nevermind xf86cfg, indeed. It wouldn't run on either of the machines I tried it on. The funny part is, it failed with "cannot read config file." So I fell back to X -configure plus vi.
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
A) Who's still running PseudoColor visuals that actually want anti-aliasing? BeOS here works fine with 256 colors, anti-aliasing and all.
B) That's probably a good idea.
C) Who cares? As long as it is cross-machine compatible, I'm guessing the XFree folks have enough clout to change the extensions and have the industry follow.
A deep unwavering belief is a sure sign you're missing something...
A) Why obther supporting ancient hardware. Mono cards? Good god! I thought palletized cards were as bad as it got! XFree86 4 is supposed to be the "second coming" if you will of X. There is no point in supporting ancient hardware. Either upgrade or stick to 3.3.6.
B) Blanking: Yes, fix it...please
C) Especially for the compile phase. The compilation instructions consist of the standard X 6.4 docs. That's just silly.
A deep unwavering belief is a sure sign you're missing something...
As for doing antialiasing behind the scenes in an X11 server, a hack like that may work most of the time, but it deviates from the definition and may break some applications. Doubtlessly, the same thing was true when Microsoft added antialiasing to Windows, but Microsoft controlled the Windows API. Hummingbird doesn't control the X11 API and if they deviate from the specs in this way, they are simply providing you with a broken X11 implementation.
Note that I have not used 3d acceleration with these boards (my employer has no need of that feature so I did not spend time configuring/testing it, and it is mutually exclusive with xinerama, which we do need).
However, I fried an SGI 1600SW monitor trying to get a quad head digital DVI G200 card to work with the multilink adapter -- I believe hardware was more responsible for this than X, but as I never saw an image (and won't risk another monitor trying to get it to work) I cannot say for certain.
We have been using XFree 4.0.1 in production systems (single headed config) for some time with good success. Xinerama will probably be deployed in a few months, perhaps even weeks depending on demand, after some more testing.
A final word on the upgrade question. I would say that, if you absolutely must have a stable system, then upgrading to the latest version of X, no matter how good the release is, is a bad idea.. Wait a few weeks while others try it out, or try it out yourself on a less critical system. Don't be one of the first to upgrade on a system which must be stable -- let others uncover any bugs/work arounds first, then upgrade once a sufficient body of knowledge/consensus exists as to the quality of the release.
I suspect you will find 4.0.2 up to your needs, but be a little patient and wait until you can be reasonably sure before upgrading.
The Future of Human Evolution: Autonomy
ok, vrml has had very little take-up as an interactive multi-user networked 3d environment, what hope for X instead? How large would an equivalent X program be to a vrml world? How much bandwidth does a GLX connection take for anything decent and what happens if you route it over the net? How light can the load and footprint be from these 3d X clients, e.g. how many clients could a normal (if you must lets say 1/2 gb dual 750) internet server deal with. What sort of 3d performance would we see on consumer OpenGL hardware? Can we let the windowz users play with us? How cool would it be? Does anyone know?
Never underestimate the dark side of the Source
God bless open source (*sniffle*)
-Legion
I mostly wrote that post because whenever I read a story about XFree86 on /. everyone bashes it. I mentioned in my post that I didn't agree with the comments that I made. You may have overlooked that. I am glad, however, that you brought up a lot of key points. It's nice to hear people defend XFree86 for a change. I try to stay away from pixmap UIs. Enlightenment was slow on my P3. Sawmill is an excellent window manager (although it still suffers from pixmap-bloat). I really enjoy the Sawmill-Gnome combo which as we all know, includes XFree86.
Keeping
As some have said, there are nv drivers on the nvidia page.
But, in the notes, it think that it says that there are some problems with the GeForce2...
They have an opensource driver available on the page as well. It is for the XFree 3.x and not 4...
I know that the SGI Linux machines are now shipping with the GeForce2 cards and that the drivers are a combined effort of nVidia, SGI and VA.
I have been told that you can find better drivers on SGI's page by downloading some of the patches for the SGI Linux systems. This may not work. I went to far and messed mine up.
I have tried using the nVidia drivers with some software on my box and it seemed to be messed up.
If you can get any further, let me know.
-I just work here... how am I supposed to know?
The mouse support providing DGA 1.0 in XFree86 4.0.1 was subtly broken and gave jumpy and unpredictable mouse behaviour which was most noticeable in Quake 3, among others. This has been fixed in the CVS Xfree86 tree for a few months now and I assume therefore it is fixed in 4.0.2.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Anyone who's regularly dist-upgrading the unstable branch for Debian have probably noticed that we're getting the the 4.0.1pre2 release candidate packages. Hopefully we're only a day or two away from having the real 4.0.2.
Kudos to G. Branden Robinson and the X Strike Force for helping us Debian users keep up!
Jay (=
> Mmm. Strom.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
> Mmm. Strom.
CmdrTaco has a thing for Strom Thurmond?
EEEEEEEEEEEEWWWWWWWWWWWWWWWW!
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
You need to build/install FreeType2 and then build/install the Xft library with FreeType2 support. Yes, this is a pain, but I expect Linux distros will include support by default.
Owen Taylor is hard at work getting Xft working with GTK+ 2.0, KDE has taken my Qt patches and incorporated them into their copy of the Qt tree. We're on our way to the magical land of anti-aliased text, and it's happening faster than I thought possible even a couple of months ago.
How? Well, the X server is Exceed and runs on Windows. I created font entires for Arial, Times New Roman, Courier New, etc., in the X server. So, an X app could request to draw with Arial if it knew they existed (which almost none do). So, the trick is to make an alias for "helvetica", "times", and "courier", and point them to the MS fonts. Now, all the X apps get the scalabe TrueType fonts and don't need to know about them.
MS may stink at a certain things, but they did a good job on fonts. Their typography website is a great read.
My point is that if it can be done without protocol extensions on a PC X-server, it should possible to do it in XFree86. Granted, the Exceed server simply passes the font draw command to Windows, which has the TrueType renderer. But Exceed could use the FreeType render, right? Or can it already, and I'm just missing out because I can't figure out how to do it?
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
I am positive that Xfree86 will be arround for a while.
;)
I am also positive that those that whine the most about some opensource code are doing the least to better it.
I am even more positive that this is not what you were looking for when you said positive comments only...
Thanks for getting all those uglies out of the way...
-I just work here... how am I supposed to know?
>>never knew VA was a non-profit org
Not intentionally.
Bwahahahahahahahaahahahahah.
Okay, so where can I download a truly transparent terminal?
----
Celebrate the finer things in life
Here's another compelling reason to put the font support in the X server instead of the application layer: if you put the font handling in the application layer, each system on which the clients will execute will have to have all the fonts those clients wish to use available on that system. Hence, the fonts available to the applications a user might run will vary depending on where he's running his applications from. This probably isn't a desirable situation.
--
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Sure, but (a) most people use a truecolor visual with at least 16 bits of depth these days, so allocating extra colors isn't a problem, (b) just because alpha information is provided doesn't mean the X server has to use it...it can draw the fonts the same way they would be drawn had they been supplied as a straight bitmap, and (c) alpha font support can be turned on or off with an option to xset(1) or, if that's not possible, a switch to the X server itself if necessary.
Yeah, but the problem is that the common API amongst all these things is Xlib and, underneath, the X protocol. Font handling is such a fundamental role of the X server that I believe newer methods of rendering fonts should also be handled by the X server.
Otherwise, you get the X server handling some fonts while the toolkits handle other fonts. That's insane! It's also wasteful.
The deal is this: users expect the fonts to look good. They don't give a shit what toolkit is in vogue at the time, nor should they. Good looking, toolkit-independent fonts can be had by implementing them at the X server level, so why isn't this being done? This may be a religious issue, but I strongly believe that if you're going to implement functionality that the X server already handles in some manner, then you should implement it in the X server. Otherwise you're just contributing to the mess we already have, namely the proliferation of toolkits that all provide roughly the same functionality but in slightly different and incompatible ways.
--
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Well, I was just going from the FAQ...
That's from http://www.libsdl.org/intro/author.html
Xfree86 is a version of X, on of many. It was not developped in 1963, X itself was developped after Windows 3.1.
Is there any reason for anyone to listen to what you have say with any degree of confidence at all.
YES!
They should feel confident that you are a truly magnificent idiot - there are many round these parts, but you are as a god to them.
Btw. Nothing else you wrote made any technological sense, either. Pull my finger, fool.
Ok, admittedly this is not my strong point (I'm more of a server hacker) but, what kind of effort would be involved to get XFree to supply all of its available fonts, automatically, to GhostScript? It seems to me that if this could be done, all installed fonts would be available on both the screen and on the printer at the same time.
This would take us one step closer to desktop parity with Those Other desktop operating systems.
--
Tired of FB/Google censorship? Visit UNCENSORED!
Xfree86 sucks. Classic example of Bloatware. Designed in 1963 by some unix hacker who wanted to run visual apps remotely via network. Everything and the kitchen sink has been hacked into the code since then. Not stable. Takes up too much RAM. Linux better come up with a good alternative if it ever wants a piece of the embedded market. Piece of crap. blah blah blah.
I think that you get the point. Since I did all of the complaining, please limit your replies to positive comments only.
Keeping
I suppose that applications will have to be specifically designed for XFree 4.0.2 for them to have antialiased fonts, right?
Alex Bischoff
---
Alex Bischoff
HTML/CSS coder for hire
So NVIDIA_GLX-0.9-5.tar.gz only contains the binary object and not the source? Damn them...
I believe what it means is that X will compile and run under Mac OS X (as it does under WinNT). So you will be able to run your X apps on a mac.
-- BLarg!
Actually, both stories got rejected within an hour of submitting each. My second one got the rejection stamp after less than 5 minutes, and there were over 230 submissions ahead of it. I dunno, maybe someone decided to flush the queue without really going over them.
Now this story comes up and isn't credited to anyone, which means Taco probably got it from the xfree86.org homepage rather than from the submission queue. Perhaps slashdot needs more descriptive rejection messages, like "rejected by timothy - reason: already submitted" so people aren't left wondering how their submissions are being used.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
Or a separate library?
I'm about to talk out my ass, but...
This is ridiculous. Why not instead: design a separate font server protocol that takes the same font specification as the older font server and outputs a font with alpha information and set up the X server to automagically detect that the font server is talking the newer protocol and treat the font data as including alpha information, then render it appropriately to the screen.
As for fonts in the font path, just have the X server detect that the file is of the new alpha-capable format and deal with the font appropriately.
I mean, the whole point behind having an abstraction like the X server that deals with fonts is that the applications don't have to know things like whether or not the fonts are antialiased...they Just Work.
So please, tell me why this won't work, and why it's not being implemented this way.
--
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
For a while there I was afraid slashdot wasn't even interested in announcing this release.
:-P
When they started putting the build online:
2000-12-19 03:22:54 XFree86 4.0.2 release(ing?) (articles,x) (rejected)
When they finished putting the build online:
2000-12-19 22:55:45 XFree86 4.0.2 is out (articles,x) (rejected)
Go figure.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
I have given up on Xfree 4.0.1 and gone back to 3.3.6 because the fonts appear to be completely messed up. At the same resolution, fonts, esp. truetype fonts, appear HUGE on xfree86. The fonts on netscape and Konqueror are especially bad. I don't know why this is, since I have setup Xfs to do the font serving and have merely set the FontPath to unix/:-1.
Sounds like your resolution settings are royally fubar'd. The renderer will try to guess the dots per inch from your monitor size and pixel resolution and will plot the fonts in an appropriate scale. It is sometimes useful to override this calculation - either
or edit your /etc/X11/xdm/Xservers file to read
To be honest, I have no idea why you would want to use XFS alongside XFree86 4.0.1. The 4.0.x family includes rendering support for bitmap, Speedo, Type 1 and Truetype fonts in X and is therefore a lot easier to set up than using an external font server. I ran 'chkconfig xfs off' as soon as I installed 4.0 and I haven't looked back.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
- standard S3 support (LOTS of "business" PCs found in companies have S3 cards - the one i am writting this onto has a s3trio64v2)
:) and there is NO way i could have one X (matrox) and one text (hgafb) setup. X will blank the text console at startup.
:)
- mono / 1bpp framebuffer / hercules support. 3.9.x had it. It vanished beginning with 4.0.1.
- an option for "DO NOT blank the damn text console/tty you're starting on". I have at home a dualhead system (one matrox + one hercules
- extensive documentation
Other than that - it's K3Wl !
--
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
If you're having trouble with your GeForce2 MX, try this FAQ.
Though I'm the first to bitch about /., it is fair to note that they used to get slammed very, very regularly for posting things too early and destroying servers before things could mirror. Whether or not they should have given you credit is one thing, but they should be commended for waiting up (one of the few things about /. that truly has improved over the years.)
IAAL,BIANLY
Comment removed based on user account deletion
I spent last night downloading XFree864 from CVS and compiling, now binaries are out! Well, I did it for anti-alias support anyway so no loss.
b le/freetype2-current.tar.gz
/usr/local
I'm writting this using KDE2's konqy fron CVS (also last night) with anti alias text and it looks great.
There is a real easy way (?) to set this up without applying patches to QT etc. A Simple HOWTO based on what I did is below HOWEVER, I have no idea if this is needed for the final 4.0.2 release.
Download, make and make install freetype2 from www.freetype.org, this should be a recent CVS checkout or snapshout, i used this: ftp://freetype.sourceforge.net/pub/freetype/unsta
Download X in source form, create the file:
xc/config/cf/host.def
To have this line:
#define Freetype2Dir
Make and install X with make World & make install.
Get an updated qt that contains the patches to use the new render, the easiest way to do this is to do a qt-copy checkout from kde's anon CVS. This already has the patches applied and a configure option to turn on render use.
Configure qt with:
./configure -xft -sm -gif -system-jpeg -no-opengl -no-g++-exceptions
make QT...... You now have a QT with render support, anything you compile against it will get anti-aliased text including the whole of KDE2.
Good luck!
A journey of a thousand miles starts with a brutal anal raping at airport security
Why would I want a volcano delivered to my door?
Wow! So you agree!
A deep unwavering belief is a sure sign you're missing something...
There's a file you can edit to change this, however I can't quite remember what it is as my Slackware machine doesn't have it.
/etc/X11/xinit/xserverrc. I just tweaked it myself.
I think its either
/etc/X11/xdm/serverrc
or
/etc/X11/xinit/xserverrc
probably the first one, I'm pretty sure its xserverrc though
I don't know how different the distros are, but on Debian it's located in
If you're only going to use the 75 dpi fonts on Debian, you may want to deinstall the xfonts-100dpi package, and put it on hold so that apt-get doesn't download newer versions of it as well. (This is how I was preventing the 100 dpi fonts from showing up previously...)
An easy way to hold packages in general:
# dpkg --get-selections > installed.txt
This will dump a list of all of the packages and their status (install, deinstall or hold; purged packages don't show up on the list). Edit the list with your favorite text editor, replacing "deinstall" or "install" with "hold" and then:
# dpkg --set-selections < installed.txt
Jay (=
However, there is a GeForce2 driver in the release, but the acceleration is little, due to the simple fact that their are not specs for an opensource GeForce2 driver. (IE: the people that developed the closed source GeForce driver, can't talk about it...) Also note, that the Radeon driver does not yet provide 3d DRI support, and that is forth coming.
Three cheers to the DRI and XFree86 guys for their continued hard work, which trully shows in this product. Please let the mirrors update, though.
Happy downloading.
------ 24.5% slashdot pure