Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
X GUI

XFree86 4.0.2 Released 249

Posted by CmdrTaco from the get-it-while-it's-hot dept.
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.
This discussion has been archived. No new comments can be posted.

XFree86 4.0.2 Released More

XFree86 4.0.2 Released

Comments Filter:
  • Hi,

    I did try turning off Xfs. It did not make
    any difference. The fonts are still huge.

    And using startx -dpi 100 seems to have no
    effect on Xfree 4.0.1. Whether I use
    -dpi 100 or -dpi 75, xdpyinfo always returns
    a resolution of 108x101.

    Magnus.
  • As much as I'd like not to have to write this, but 4.0 was extremely unstable for me (daily server crashes due to SIGSEGV, no 3D involved at all, only an old Matrox Millenium). 4.0.1 is a lot better, but still goes down once in a while with the same problem (same stack trace even). Can't wait to get 4.0.2 installed...

    --

  • Look under the SlashDot FAQ, you'll get some answers. Also note that not everyone is interested in X (dunno why, but they aren't). Specifically, certain SlashDot posters...

    It's all about the Karma Points, baybee...
    Moderators: Read from the bottom up!
  • XVideo is an extension to X to allow mpeg/video accelerations, and tv tuner support, and a few other things.
    Does this mean that the picture from TV tuners will improve? A friend and me have exactly the same TV tuners (Hauppage Cinema, BTTV driver). Under NT his picture quality is worse than the one I get under Linux/X3, but when he upgraded to Windows 2000 it improved a lot, and now the worst quality is on my Linux box. Would an upgrade to X4 improve this?
  • A lot of people here missed that XFree86 4.0.2 has support for ATI Radeon and Nvidia GeForce 2 family of chips. Well, 3D support is not 100% functional, but you can get 2D acceleration and use your card with KDE or GNOME.
  • Dude, your system needs tuning!

    My 333 mhz celeron overclocked to 415mhz, 128Mb ram, UDMA/33 HD, loads KDE from startx in about 13s. (no app sessions restored). This is just a stock Mandrake 7.2 installation, with some hdparm fiddling (-d1 -c1).
  • Dont worry, I count at least 5 grammatical errors; this includes the huge run-on sentance connected by a kilometer of commas.

  • So how much of this is Linux only? (Score:2)

    by Anonymous Coward
    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?
  • No silly... it means that you can install and run it on Darwin or MacOS X PB! (which is way cooler :) ) and eventually run X-apps within that environment.

    The guy doing the work for OS X and Darwin is on the Darwin mailing lists right now fielding bug reports and such. Fun to watch! :)
  • According to SGI, GL means Graphics Library, and not Graphics Language. Besides, what language would that be?

  • Well, the real reason they aren't using DRI is because they are making a close-as-possible port of the Windows drivers. I guess they think this method is much more superior; it may be, but I dont like it one bit. However, they could be total bastards and not release anything at all.

    PS: if there is any FreeBSD + NVIDIA people out there that can code drivers you may be interested in that NVIDIA will be happy to rebuild the closed sourced parts of the drivers if someone will port over all the agp/interrupt code of the open linux module. I am not sure of the status as of yet (last i heard about it was 2 weeks ago), but contact madcat' or ripperda on #nvidia (irc.openprojects.net) if you want to do this.
  • What the hell are you talking about? I do full time Java development under the Linux kernel 2.4 (test 12), and everything works perfectly. Just grab the JDK from the Sun site and it should function out of the box.
  • Yep. Currently we're running Linux on an embedded system with a gig of RAM. Its got X clients, but since the only way to connect to it is via ethernet or serial, there's really no purpose to running the server...
  • A small follow up to my own post, from what I can gather some drivers don't have support for the render, I have a laptop here using a ATI Rage Pro (MACH64) and I don't get anti aliased text on this machine (RENDER not availible on display messages). The TNT2 in the other machine works fine however. Also, thanks to the xfree team, 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.
  • 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?

  • Re:Nvidia Detonator drivers? (Score:3)

    by xercist ( 161422 ) on Tuesday December 19, 2000 @07:54PM (#547327) Homepage
    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.

    irc.openprojects.net, #nvidia
    /ctcp ice-dcc xdcc list

    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 :(

    --
  • I'm sorry... where is that underrated?

  • I think you're confused. (Score:5)

    by bconway ( 63464 ) on Tuesday December 19, 2000 @05:06PM (#547329) Homepage
    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.
  • Please, dear LORD, let it have the GeForce driver and WORK!!! There is no way I'll EVER be able to compile the server from the CVS rep.
  • well.. you shouldn't read slashdot for software updates. you should watch www.freshmeat.net for that.

    tres
    ---
  • XFree 4.0 really needs a 2.4 kernel (you can run it with a 2.2 kernel with certain patches, but that is not a 'standard').

    Hmm, interesting... considering I've been running XFree86 4.0 (and newer) on 2.2.x kernels (with no extra patches) since it was released.

    The only extra kernel-related stuff I installed were the NVidia driver modules (which didn't require me to patch the kernel at all). And that was only for OpenGL hardware acceleration (the standard nv driver in XFree86 4.0 worked fine for everything else).

  • very confused... (Score:4)

    by jmd! ( 111669 ) <jmd.pobox@com> on Tuesday December 19, 2000 @03:43PM (#547334) Homepage
    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?

  • Wow! Features! (Score:3)

    by be-fan ( 61476 ) on Tuesday December 19, 2000 @03:46PM (#547339)
    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. [xfree86.org]

    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.
  • "Just the toolkits" means: NO! It does not work for existing programs.

    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.

  • Re:Font antialiasing NOT compiled by default (Score:3)

    by keithp ( 139560 ) on Tuesday December 19, 2000 @07:56PM (#547350) Homepage
    The integration is not within XFree86, but of FreeType2 with our binary build and installation process. I should have started that a couple of weeks ago, but got caught with various other activities (like getting Qt working).

    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?

  • Re:(+1, Thanks!) (Score:4)

    by nathanh ( 1214 ) on Tuesday December 19, 2000 @05:33PM (#547362) Homepage
    One followup question...in Xfree4, if you have DRI working, is all 3d rendering through Mesa done as direct rendering? Windowed and fullscreen?

    Yes, one of the design goals of the DRI was accelerated windowed 3D. Sometimes a certain feature might only be available when fullscreen rendering (eg, page-flipping) but these are exceptions to the rule.

    Another design goal of the DRI was multiple simultaneous 3D clients. At the moment you might lose hardware acceleration for some clients if you've got too many OpenGL clients running at the same time. It depends on the hardware.

  • Bullshit. The application does not have any way to know what the exact bitmap being drawn for a font is (other than drawing it and grabbing the screen). Thus the "bit accurate control" argument is wrong. When I draw a font with xlib I want to see the font as nice as possible. I probably make a few assumptions that it wont extend more than 2 pixels or so outside the bounding box but otherwise my programs (and everybody else's) do not rely on bit accuracy! (if you are really paranoid, the antialiasing can be turned off when xor mode is enabled).

    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!

  • This actually sounds like an ok solution. A few problems, which may be annoying:

    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."

    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 .x releases, much less .0.x ones.

    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.
  • Eh? GeForce2 support was supported before the NVidia drivers were released for BeOS, but who cares, X support is much better than BeOS (*cough* OpenGL 1.1.2 through GLX
    *cough*)
    >>>>>>>>>>>>>>
    Yea yea, shut up. I forgot about the NVIDIA drivers. Well, at least BeOS had support before the XFree guys did.

    1) If it uses XAA, why does it only accelerate on MGA?

    Perhaps because XAA falls back to software function if the hardware is not there (or not implemented yet), much like BeOS.
    >>>>>>>>>>>>>.
    Every OS falls back on software, but XAA (X Acceleration Architecture) is (by definition) not a software rendrer.
  • Qt, Gtk, twm:

    • 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?

  • Re:Antialiased fonts requires toolkit support??? (Score:4)

    by q000921 ( 235076 ) on Tuesday December 19, 2000 @08:31PM (#547379)
    The X11 protocol gives applications bit-accurate control over drawing. The spec doesn't just say that you call XDrawText and something vaguely resembling the text will appear in the window roughly where you want it to, it defines the exact way in which the text bitmap gets combined with the window contents. Furthermore, the X11 server is not permitted to allocate extra colors (grey values) just because it feels like it; the application may require control over those values itself.

    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.

  • Re:Wouldn't you know it! (Score:3)

    by GrenDel Fuego ( 2558 ) on Tuesday December 19, 2000 @05:43PM (#547383)
    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.

  • Re:Render (Score:4)

    by keithp ( 139560 ) on Tuesday December 19, 2000 @08:37PM (#547385) Homepage
    Render is a new rendering model for the existing windowing model; we'll need another extension for a shiny new translucent windowing model. The extension for that will be simple, but the internal reorganization of the X server will be rather gory. Exactly the opposite of the Render extension where designing the extension was the fun part and implementing it was straightforward.

    As for Render, it's got everything but separate alpha, polygons and image transformations. Put another way, it's got just enough to manage anti-aliased text and alpha compositing images.

    Volunteers to create software renderers for triangles, trapezoids and image scaling are welcome to help. For the polygons, all that I want is code that takes a triangle (or trapezoid) and generates an A or ARGB map, that way I can layer the result over existing compositing acceleration.

  • 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.

  • Re:What about improved game support?? (Score:2)

    by Anonymous Coward

    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 ;)
  • Exactly what I said. The NVIDIA OpenGL ICD doesn't work without the NVIDIA X driver. Meaning that you have to choose between the NVIDIA nvidia driver (3D) or the XFree86 nv driver (Xrender)
  • 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.)
  • 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.
  • 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.
  • 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)
  • 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.
  • 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.

    ________________________________________
  • 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) 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.

  • Re:Antialiasing support? (Score:4)

    by q000921 ( 235076 ) on Tuesday December 19, 2000 @08:53PM (#547409)
    As far as I can tell, Microsoft didn't invent much of the typographical technology you point to--most of it came from Apple, Adobe, Bitstream, and many other sources.

    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.

  • I've used 4.0.1 on the following cards with excellent success (testing xinerama at work, etc.)

    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).

    • Guillemot (Hercules) Couger PCI (Nvidia TNT2/M64)
    • G400 dual head
    • G400 dual head/digital extention
    • G450 dual head
    • G200 single head (agp & pci)
    • Matrox Millenium II
    • Voodoo3
    • Various ATI cards (I can no longer recall the specific models)
    • FB-dev with kernel frame buffer support

    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.
  • 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?
  • I installed slack on my work laptop a couple of weeks ago, only to find that X didn't support the S3 Savage chip except as a generic framebuffer (slow and low resolutions only). Someone asked me what I was going to do and I replied, "I'll wait a week for someone to write a server." Well, it was two weeks, but here we are.

    God bless open source (*sniffle*)

    -Legion

  • Your reply to my post hit on a lot of key points that I agree with fully.

    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.

  • Re:Conspicuously absent... (Score:3)

    by tolldog ( 1571 ) on Tuesday December 19, 2000 @04:07PM (#547434) Homepage Journal
    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.

  • Re:DGA support in XFree86 4.0 and above ... (Score:3)

    by tjwhaynes ( 114792 ) on Tuesday December 19, 2000 @04:31PM (#547439)

    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

  • Anyone who's regularly dist-upgrading the unstable branch for Debian [debian.org] 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 [debian.org] for helping us Debian users keep up!

    Jay (=
  • > Mmm. Strom.

    --
  • > Mmm. Strom.

    CmdrTaco has a thing for Strom Thurmond?

    EEEEEEEEEEEEWWWWWWWWWWWWWWWW!

    --

  • Re:Font antialiasing NOT compiled by default (Score:5)

    by keithp ( 139560 ) on Tuesday December 19, 2000 @06:36PM (#547449) Homepage
    FreeType 2.0.1 is sitting in XFree86 CVS, but it hasn't been included in the binary releases; there just wasn't time for the kind of integration and testing we would have liked. There aren't any license issues, FreeType2 uses a license which is compatible with the regular XFree86 license.

    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.

  • I have an old Voodoo2 and Glide + Mesa + X3.3.x crashed constantly while running accelerated programs, and occasionally even locked the system up tight (Linux 2.2.1x).

    I've been using X 4.01 for several months now. OpenGL stuff is MUCH more stable then it was under X 3.3.x. Not a single lockup so far, and I don't remember the last time it crashed.

  • Apps doesn't need to be written to take advantage of anti-aliasing. I run an X server (not XFree86) that provides anti-aliased, hinted, TrueType fonts to all X legacy applications.

    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 [microsoft.com] 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 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...

  • Re:very confused... (Score:5)

    by nathanh ( 1214 ) on Tuesday December 19, 2000 @04:35PM (#547466) Homepage
    Is there any text that explains the new XFree 4 infrastructure in plain english?

    Ok, here goes...

    • GL: Graphics Language. More commonly called OpenGL, a graphics library developed at SGI. SGI owns the OpenGL trademark but they recently relaxed the licensing and released conformance tests for OpenGL. There used to be literally dozens of 3D APIs but only OpenGL and Direct3D seem to have decent marketshare/mindshare these days. OpenGL abstracts 3D so the programmer doesn't have to know about projections, lighting, rendering, texturing, etc.
    • GLU: OpenGL is pretty good but doing some common operations is a regular pain in the proverbial. GLU is a platform independent library that will build spheres, test collisions between 3D shapes, determine if a point is inside or outside a 3D shape, etc. GLU works on top of OpenGL.
    • GLUT: OpenGL is platform independent but certain operations (like creating windows, receiving mouse clicks, resizing windows) change across OpenGL platforms. GLUT lets you write a single application that will compile and work on Windows, X11, MacOS, etc. GLUT is quite limited and is primarily used for simple demonstration programs rather than full blown applications.
    • GLX: X11 is a networked windowing system. Your client and your server might be on different machines. GLX packages up OpenGL commands into network packets, spits them across the X11 network pipe, then unpacks them at the other end. This lets you run accelerated 3D remotely: the client could be running on a mainframe, crunching through millions of FP operations, and your 3D display could be a cheap Linux/NVIDIA box. This is sometimes called INDIRECT RENDERING.
    • Mesa: Brian Paul wrote a free open-source implementation of OpenGL called Mesa. The name has no hidden meaning, it just sounds nice. The original versions of Mesa only did software rendering. More recent versions have had accelerated drivers for Glide, DRI, Direct3D, etc.
    • DRI: Indirect Rendering is slow. SGI figured this out many years ago and created something called Direct Rendering. Direct Rendering lets the client talk directly to the video hardware. On UNIX this is quite complicated (because of permissions, multiple users, security, hardware contention) so an intricate software design called the Direct Rendering Infrastructure coordinates everything. The DRI used on Linux (designed and implemented by Precision Insight, now part of VA Linux) requires certain features only available in XFree86 4.0.
    • Utah-GLX: An Indirect Rendering implementation which runs on XFree86 3.3. It is indirect because every OpenGL command gets stuffed into a packet, sent over the X11 network connection, unpacked at the other end, then rendered. There is a "Direct Rendering Hack" which only works with the Utah-GLX Matrox driver. Utah-GLX is slightly slower than the DRI but had the advantage of being simpler to implement, so it was available with more drivers much earlier than the DRI was.
    • SDL: OpenGL only defines graphics (2D and 3D). The people at Loki needed to handle cdroms, audio, mixers, joysticks, keyboards, mpeg playback, etc. They created a library called SDL which abstracts all the things that games need. SDL relies heavily on libraries like Mesa to do the grunt work. You can think of SDL as a more powerful version of GLUT.
    Does DRI replace Mesa?

    No. Your client software speaks to Mesa. Mesa has a DRI driver which sets things up with XFree86 4.0, gets hardware access to the card (using the card-specific kernel module), then starts blitting away merrily on the card (Direct Rendering).

    Does Utah GLX replace DRI for cards it supports?

    No. You can think of Utah-GLX and DRI as two seperate projects trying to achieve the same end-result, but in different ways. The DRI is probably the best long-term solution. The two projects seem to work in cooperation fairly well. Many Utah-GLX developers are also DRI developers.

    Is Mesa even needed?

    Most definitely.

    Is plain Mesa included in the Xfree source tree, or is it a fork?

    The Mesa in the XFree86 tree is the Real Official Mesa. The Mesa project is still run independently but the code is regularly "synced" with XFree86.

    If I don't have a 3d card, does mesa still install as a software renderer?

    Yes.

    Does this give better performace over the 1fps syndrome in xfree3/windows95?

    No.

    Are any of the projects I named obsoluted by the new infrastructure? (utah glx comes to mind...)

    Utah-GLX is the only 3D accelerated option for XFree86 3.3, so it isn't an obsoleted project yet.

  • Re:Slashdot theft? (Score:5)

    by Anonymous Coward on Tuesday December 19, 2000 @04:35PM (#547468)
    >>never knew VA was a non-profit org

    Not intentionally.
    Bwahahahahahahahaahahahahah.
  • Okay, so where can I download a truly transparent terminal?
    ----
  • 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.

    --
  • We are talking about different things here...

    With XVideo you can:

    • Fetch the video from external sources (like TV card, camera, and so on). This is where video4linux "backend" comes to play. Then you can put it into file or on the screen.
    • Put the video on the screen (either playing from file, or from live source). This is the place, where scaling and filtering is used.
    Scaling is.. well scaling. There is nothing to explain.

    Filtering is only done when scaling, so the picture will not appear pixelated (see here [tripod.com]). There is no reason to use filtering, when you are displaying picture 1:1. Obviously, in this case you would not use scaling either.

    So, when someone is pulling bad picture from his TV card, Xv can not "enhance" it (while watching 1:1).

  • The X11 protocol gives applications bit-accurate control over drawing. The spec doesn't just say that you call XDrawText and something vaguely resembling the text will appear in the window roughly where you want it to, it defines the exact way in which the text bitmap gets combined with the window contents. Furthermore, the X11 server is not permitted to allocate extra colors (grey values) just because it feels like it; the application may require control over those values itself.

    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.
    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.

    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.


    --
  • SDL was not written by Loki, they use it, it was started/written by ken slouken...

    Well, I was just going from the FAQ...

    Sam Lantinga, Lead Programmer for Loki Entertainment Software. Loki Entertainment is a company devoted to porting top games to Linux. You can find out more at http://www.lokigames.com/
    Background:
    • Author of the Simple DirectMedia Layer (SDL)

    That's from http://www.libsdl.org/intro/author.html

  • Haha, calm down.
    >>>>>>>>>
    Arg.

    Congratulations, another selling point for BeOS! NOT! Adding support to the nv driver (which existed before
    the BeOS drivers) was as simple as adding the PCI id's of the Geforce2 (MX) cards.
    >>>>>>>>>>>>>>..
    But the fact remains that for a few weeks, OSS hardcores unwilling to use the NVIDIA-supplied drivers were able to use their cards in BeOS rather than Linux! Wait... the BeOS drivers are closed to... damn it, I'm confusing myself...

    You're blowing smoke right?
    >>>>>>>>
    Don't think so. It seems that I'm correct, XAA provides a common interface for hardware acceleration. You missed my point: If XAA automatically delegates functions to hardware drivers, than any driver that implements XAA hardware acceleration will accelerate any app that uses XAA. You answered my question indirectly though, I didn't know that XRender added new functionality to XAA itself that new cards have to implement.

    OT: Meanwhile Be is ready for a buyout! With a market cap of just above $30M they are ripe for the picking.
    And to think JLG wanted $400M for a company that apparantly is only good at making PC demos :)
    >>>>>>>>>>>>
    RedHat is only good at making server OSs whats you're point? I mean there's no point fighting over it, Microsoft is still king.

    Actually marketing and selling their stuff is foreign to the current management. Yep, as a former be fan myself it's really sad to see them struggle like this.
    >>>>>>>>>>>>>
    If you've read BeNews lately, you'll find out that they're doing pretty well for themselves. If their deals pan out, then they should become competitive.

    But hey, nice demos and c00l technology simply aren't enough to survive.
    >>>>>>>>>
    Coming from a Linux user? What, besides c001 technology (and free stuff) IS Linux?

  • Re:Finally Stable (Score:2)

    by Anonymous Coward
    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.
    --
  • I'll save everyone from having to Bitch about Xfree86. I really don't feel this way, but it is apparent to me that whenever Xfree86 stories appear on /. the readers feel obligated to state the following:

    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.

  • I suppose that applications will have to be specifically designed for XFree 4.0.2 for them to have antialiased fonts, right?

    Alex Bischoff
    ---
  • Um, that is probably because VRML is more of a file format than an "interactive multi-user networked 3D environment". There is, however, hope [sourceforge.net]... ;^)

  • Re:(+1, Thanks!) (Score:5)

    by nathanh ( 1214 ) on Tuesday December 19, 2000 @10:49PM (#547503) Homepage
    only applications run with proper permissions can access the video hardware. DRI is a purely direct rendering interface

    Correct.

    it doesn't abstract away desctructive parts of the card (i.e. if users had access to the accelerated instructions, they could basically 'blit' a new kernel image from graphics memory, to get around the normal memory protection and security permissions).

    False. Several of the drivers do special things because of these security issues. For example, cards with programmable DMA destinations have those parts of the cards hidden as kernel ioctls.

    Because of this, you must be root, or applications must be setUID root in order to get direct rendering - otherwise they will render in software.

    False. One of the design goals of the DRI was non-root direct hardware access. There is further discussion of this topic here.

    http://www.precisioninsight.com/dr/drm.html

    In particular... "The direct-rendering clients, however, do not run as root, but still require similar mappings. Like /dev/mem, the DRM device interface allows clients to create these mappings..."

    Part of the purpose of projects like GGI/KGI have been the long-standing goal of creating a kernel API to allow as direct as possible access to the video card without allowing the user to damage the system.

    The KGI has different design goals. It is closer in spirit to linux-fb. It is arguably not suitable for high speed 3D like the DRI.

    Your understanding is a little flawed. There is some very good information on dri.sourceforge.net and www.precisioninsight.com. The whitepapers on Precision Insight's website are excellent.

  • So NVIDIA_GLX-0.9-5.tar.gz only contains the binary object and not the source? Damn them...

  • Re:very confused... (Score:5)

    by amccall ( 24406 ) on Tuesday December 19, 2000 @04:15PM (#547507) Homepage

    Rolls up sleeves...

    Ok. DRI is also known as "Direct Rendering Infrastructure", it provides a method of access to the graphics hardware which eliminates some of the layers of abstraction in using OpenGL see http://dri.sourceforge.net, for info.

    GL/GLU/GLX are all part of a 3D API which allows applications to use graphics hardware. GL provides the core functions, GLU provides extensions, and GLX relates to how the those relate to X.

    Utah GLX was an effort to produce hardware accelerated 3d drivers for X a little while back for XFree 3.3.x... There is still work going on it.

    Mesa is a "compatible" GL, since they can't legally call it OpenGL. Mesa is the basis for both Utah-GLX and DRI. The methods which the driver works are different though.

    SDL is a cross-platform developer library which allows low-level graphics programs to be easily ported. (It also does sound, input, and timers.)

    XVideo is an extension to X to allow mpeg/video accelerations, and tv tuner support, and a few other things.

    The list of the features in the new render extension can be seen on the main page, but the biggie is the alpha-channel support. Most programs will not take advantage of it immediatly, but in time I think we'll see some nice things come from it.

  • Re:Darwin/Mac OS X??? (Score:3)

    by BLarg! ( 129425 ) on Tuesday December 19, 2000 @04:18PM (#547510)
    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.
  • 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.


    --
  • Bug fixes: Yea, those.

    Bugs are my concern. I don't care at all about anti-aliasing, but would like the 3d accl to work when it's stable. I *must* have a stable machine though, so have held off on upgrading.

    My short question. Is it time to upgrade? Are enough of the bugs worked out for this to be on my primary.

    --

  • do they even READ story submissions? (Score:3)

    by itarget ( 168249 ) on Tuesday December 19, 2000 @03:35PM (#547521)
    For a while there I was afraid slashdot wasn't even interested in announcing this release.

    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. :-P
    ---
    Where can the word be found, where can the word resound? Not here, there is not enough silence.

  • Re:Antialiasing support? (Score:3)

    by QuoteMstr ( 55051 ) <dan.colascione@gmail.com> on Tuesday December 19, 2000 @03:35PM (#547523)
    No, just the toolkits. Recently, there was even a patch for XEmacs posted that allowed this to work with it.

  • 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

    startx -dpi 100

    or edit your /etc/X11/xdm/Xservers file to read

    :0 local /usr/X11R6/bin/X -dpi 100

    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

  • Still missing... (Score:3)

    by psergiu ( 67614 ) on Tuesday December 19, 2000 @11:02PM (#547525)
    - standard S3 support (LOTS of "business" PCs found in companies have S3 cards - the one i am writting this onto has a s3trio64v2)

    - 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 :) and there is NO way i could have one X (matrox) and one text (hgafb) setup. X will blank the text console at startup.

    - extensive documentation :)

    Other than that - it's K3Wl !


    --

  • Re:Antialiased fonts requires toolkit support??? (Score:5)

    by keithp ( 139560 ) on Tuesday December 19, 2000 @11:07PM (#547528) Homepage
    Fonts in the core protocol are in much worse shape than you think.
    • No advanced font information (like kerning tables)
    • No standard way for applications to provide their own fonts (PDF documents can embed fonts)
    • No support for vertical/diagonal escapements

    The first problem would have required a significant new extension to codify the information available in current font files and still not solve the problem for future font file formats.

    The second has traditionally been solved by creating an application-specific font server. What a kludge.

    The third would be relatively easy to add to the existing core fonts, but would have required requests to transmit the new metric information.

    Instead of a collection of ugly kludges, a new font mechanism was created placing the burden for locating and loading fonts squarely in the clients space while the X server handles what it does best -- drawing stuff on the screen. While this has been done in the context of the Render extension, the advantages for applications and toolkits is enormous. You should see Owen's changes to Pango using this stuff, he's able to directly access the font file information for composing glyphs together.

    However, I agree that building a system which makes all font handling dependent on the toolkit is a bad idea. Towards this end, I've started on the Xft library which is the part of XFree86 designed to make font file access and glyph rasterization consistent across all X applications. Applications are free to go around Xft and do their own thing, but Xft is a thin enough layer and provides transparent access to the FreeType library which accesses the font files so I think this won't happen. I've built Xt applications, changed Tk and Qt and seen changes to GTK+ all using Xft. The results provide identical glyph images and a single location for font configuration throughout my desktop.

    Probably the biggest advantage of the new system is that even if the current Xft library turns out to be irreparibly broken, we can pitch it on the scrap heap and start over without changing the X server. Extensions are hard to get propagated to every desktop; libraries can be shipped with applications and installed without trouble.

    I added sub-pixel sampled text with very minor changes to the Render protocol; I can add sub-pixel positioned text without any changes at all. Glyphs are now rasterized on-demand, rather than having the entire font done when opened. This means using 10646 encodings is finally feasible within X; Qt, Tk, Java all use 10646 internally, now X can support that natively with no tremendous performance hit.

    This can be viewed as the Unix lesson all over again; parts of the system which can easily be done outside of the "kernel" (X server) should probably be done there. In this case, the advantages are overwhelming.

  • If you're having trouble with your GeForce2 MX, try this FAQ [mcdownloads.com].
  • 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.)

  • Comment removed (Score:5)

    by account_deleted ( 4530225 ) on Tuesday December 19, 2000 @04:53PM (#547542)
    Comment removed based on user account deletion
  • GL: Graphics Language. More commonly called OpenGL

    Just one precision: GL != OpenGL. What we're talking about here is OpenGL. GL was an SGI-only library, which is now replaced by the more open (obviously) and cross-platform OpenGL. The syntax is similar, but one of the differences is that OpenGL doesn't manage windows by itself, so it can work for X, Windows, ...

  • Wouldn't you know it! (Score:5)

    by _ganja_ ( 179968 ) on Tuesday December 19, 2000 @04:55PM (#547545) Homepage
    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.

    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/unstab le/freetype2-current.tar.gz

    Download X in source form, create the file:
    xc/config/cf/host.def

    To have this line:
    #define Freetype2Dir /usr/local

    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!
  • Isn't XEmacs an application?

    Uh, no. Since the hell when is anything Emacs just 'an application'? If RMS was dead, he'd be turning over in his grave at that suggestion. Or something.

  • Stromboli (Score:3)

    by JCCyC ( 179760 ) on Tuesday December 19, 2000 @05:01PM (#547549) Journal
    (...) 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.

    Why would I want a volcano [mtu.edu] delivered to my door?

  • Wow! So you agree!

  • Slightly off topic: holding Debian packages (Score:3)

    by TrentC ( 11023 ) on Wednesday December 20, 2000 @07:34AM (#547553) Homepage
    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.

    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 /etc/X11/xinit/xserverrc. I just tweaked it myself.

    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 (=
  • AFAIU all apps have to do for anti-aliased text is use the new Xft library which in turn uses the Render extension. Qt has been hacked with support for it, and I guess it shouldn't be too hard for the GNOME libraries to do so as well.

    --

  • Re:Conspicuously absent... (Score:5)

    by amccall ( 24406 ) on Tuesday December 19, 2000 @03:39PM (#547557) Homepage
    ATI is providing specs and paying VA Research(I believe) to develop open source drivers. NVidia has decided to keep their drivers closed source.

    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.

  • Updates to nv for GeForce2: Hah! BeOS had GeForce2 support before X!

    Eh? GeForce2 support was supported before the NVidia drivers were released for BeOS, but who cares, X support is much better than BeOS (*cough* OpenGL 1.1.2 through GLX *cough*)

    1) If it uses XAA, why does it only accelerate on MGA?

    Perhaps because XAA falls back to software function if the hardware is not there (or not implemented yet), much like BeOS. 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.

    XRender support will be (unofficially) leaked by mid Janaury. This is from a reliable source. So right now it's Render vs 3D yes. At least there's 3D, no such support on BeOS.

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close