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 3.9.18 Today, v4.0 in March 188

Posted by CmdrTaco from the take-awhile-to-compile dept.
John Fulmer writes, "The fourth and final beta of XFree86 3.9.x has been released and up on their ftp site. From the announcement: 'This snapshot version is 3.9.18. We are planning to release 4.0 in early March 2000.' You can download (source only) from here. "
This discussion has been archived. No new comments can be posted.

XFree86 3.9.18 Today, v4.0 in March More

XFree86 3.9.18 Today, v4.0 in March

Comments Filter:

  • Re:One step closer to 3D in Linux (FBSD?) (Score:1)

    by Anonymous Coward
    > So to make use of DRI in XF86Free 4.0, what do you do when you have FreeBSD or Linux 2.2? or
    > OS/2? Or any of the other OSes on which XFree runs?

    You can port the DRI driver in Linux 2.4.

    It's even under the X11 license, not the GPL, which should make all you zealots out there happy :)

  • Re:Overlay Support (Score:1)

    by Anonymous Coward
    Overlays are cool. The point is that you create a memory-surface in vid-mem and fill it with whatever you want to view and then register it with the card giving the card info on position and scaling for the overlay. Then when the card is going through the primary surface drawing all the stuff thats in there normally it replaces the parts of the primary surface that has a corresponding overlay with the overlay graphics. The point of this is that if you are watching a movie or playing a game that updates its display often it can use an overlay to draw on and can therefore get around accessing the primary surface at all (and therefore all windows that would normally be drawn over stays untouched under the overlay), you can also use it to paint stuff on top of the rest of the GUI (since its done in hardware at the time of display-update you are guaranteed that the overlay is on top of everything).. Under windows its commonly used for screenbuddies and such stuff that has transperancies too.. Excuse my bad english
  • yes. i was running it with two different cards with two different monitors of two different sizes running two different resolutions during the .16 release. had to stop when someone needed the second monitor, but it was beautiful.
  • How about "Cause Rob wanted to and it's his website." I give wicked props to the job Rob and Hemos did even back when they weren't getting paid for it.

    Quit whining and set up a better site if you dont like the way /. does it.
  • I was wondering the same thing, and did a bunch of research last weekend. It looks to me like the G400 is the obvious choice. It has open source drivers and its performance is good. But now should I get the single headed or dual headed model? :-)

    Can anyone think of a good reason to go with something else or a reason not to go with it?
  • Okay so I have a Voodoo 2, and every time I start Quake 1, 2, or 3, or UT, something breaks and I have to reboot because I can't see anything even if I try switching consoles. If I try this snapshot will it use my Voodoo 2 in a different way so it might work?
  • I can't remember where, if someone does please post, but aren't there libraries that render anti-aliased fonts at a decent speed?

    If so, are they fast enough and robust enough to be used as a standard? Or can they be incorporated into GTK+ and Qt?
  • I would REALLY like to know also. I dug through the mga driver source and have found nothing relating to g400 dual head support. This is the #1 feature myself, and most of my friends with g400s want.
  • please explain in what ways. Utah-GLX already has its own direct rendering code.
  • Simply, no. XFree doesn't know (or care) about Voodoo/Voodoo2 boards. That's strictly an issue of Glide 2.x working properly with the card... Make sure you have the right version of the Glide library.
  • Actually, those extra 8 bits are for alpha (transparency)... but they are rarely used. So it's not like they're JUST there for padding the pixel data out, but that ends up being their general purpose anyway.
  • s/^([^#]*)#.*$/$1/; # Comments? What for? instead, simply use: s/#.*$//;
    --
    Whether you think that you can, or that you can't, you are usually right.
  • A "quantum leap" forward is, literally, a miniscule advance.

    Not to sound whiny, but that's incorrect.

    A "quantum leap" is movement from one location to another without moving through the intervening space. Period. There's nothing in the definition of a quantum leap that puts any constraints on the distance, although it is true that most quantum leaps occur over a very tiny distance indeed.

    If XFree86 4.0 includes many new features that weren't in the previous version, so we get them all at once rather than getting them one at a time, then the metaphor of a quantum leap is accurate and appropriate. Since I hope there is in fact more than one new feature in this upcoming version, I do indeed hope it's a quantum leap forward...

    --

  • 3.9.18 is damn speed AND it works with netscape!
  • Rarely used? I know many people using this feature... including myself, most importantly :). I have twin 21"ers and a G400 max just begging XFree to support it... until then I'm stuck, painfully using AccelX which sux (imho) and I had to shell out the $ for... *sigh*

    But XFree 4.0 is looking very sweet. These guys are awsome.
  • I hope I'd notice the difference between 600MHz and 5-8MHz :-)
    --
  • I just looked at one of those cards. Pretty bare. Your first suggestion sounds about right.

    Well, at least now I have some place to put my TNT2 (having replaced it with a Voodoo3 in my home machine -- oh, if only nVidia hadn't made us wait for XFree 4.0!)
    --

  • Yeah. In one specific area.
    --
  • We recently got 5 new machines at work and they all had 32MB ATI Rage128 Pro cards (can't recall the exact name - there was a two letter code in there somewhere). We also got some nice crisp 19" monitors so for the first time, we're enjoying 1600x1200 desktops.

    One problem was immediately apparent. When large chunks of the screen need to be moved around, like when a window is dragged or its contents scrolled, the display lags. It isn't just that movement is choppy, it actually lags. You pick up the window, drag, release, and watch the window move along the path you traced over the next second or two. Scrolling is the same, and that really kills you. Imagine having to wait for your machine to recover after scrolling.

    This happens in Win98 and NT. In XFree86, there's an even bigger problem: severe font corruption when acceleration is turned on. This leads me to believe the acceleration function for moving/copying regions is broken on these cards and has been disabled in the windows drivers to prevent the same font corruption symptoms from showing up.

    I can't be certain this isn't related to some of the other hardware in these machines, but I can't be certain these cards aren't simply broken either, so I recommend you check for these problems before buying a Rage128.
    --

  • Overlays are extra bits that control the color and thus look like a drawing on a clear sheet laid over whatever was on the screen.

    The simplest implementation is to add 1 extra bit to every pixel. If the bit is on, the pixel draws red (or whatever the overlay color is). If the bit is off, the normal color is drawn.

    The advantage is that the normal color is not destroyed by turning on the bit, so the bit can be turned off to reveal the original image. If the original image is expensive to calculate the user interface is sped up a lot. This is similar to using XOR but looks much better.

    Modern overlay hardware has 4 or 8 or even 24 bits so that many colors (2^n-1) can be drawn in the overlay.

    However the advantages of overlays have become less and less over time, due to many reasons: Drawing is getting much faster so the delay of redrawing the background is ok. Double buffering can make the drawing not blink, which may make it less objectionable than the speed loss due to not using the overlay (double-buffered overlays are very rare). Overlapping windows means a program needs to be able to recreate the background image from scratch, eliminating one of the programming advantages of overlays on ancient systems. Modern users are less tolerant of the rubber-banding or outline GUI style that a limited-color overlay forces. And the limited colors usually means totally seperate drawing code must be used to preview in the overlay, resulting in more bugs and programming effort. And you usually have to make your program work anyway if no overlay hardware is available, for portability.

    I have pretty much restricted use of the overlays to rubber-band boxes because of this.

  • Problem:
    It seems that everyone is talking about 3D support, while I consider that Xv support in the 4.0 might be as revolutionary as the hw 3D drivers. While DVD is making headlines, not even the MPEG1/VCD is supported properly; and the reason is the lack of basic-level support for hardware assisted motion video viewing.

    Questions:
    As I understand, the 4.0 offers X video (Xv) extension support, which basically provides API for the hardware video scaling (with interpolation), overlaying and colorspace conversions. Does the Xv API also allow the support of iDCT and motion compensation hardware found in the newest video cards (which could be used to dramatically reduce DVDs CPU requirements) ? And what Xv:s relation to video input / output devices (both integrated and external) ? Is the Xv extension support currently implemented in any hardware drivers (I think G400 has some support, but whats the state of it ?) ? Is there any video-playing software/video libraries available, which support the Xv in the 4.0 ?
  • I think all of the former X servers from XFree86 were kind of trash. Having one server with many
    loadable drivers is something they should have
    done from the beginning.
    So, it is a step in the right direction.
    I will try it.

    BUT:
    * It still consumes enormous amounts or RAM,
    between 28-48 MB on my machine.

    *I would call it slow when compared to other
    windowing systems like win32, or the system that
    BeOS has.

    * It still doesn't have real transparency, don't
    come with things like Eterm, because that is not
    real transparency.

    * It does not have anti-aliased fonts.

    * It is not multithreaded, and that would, IF
    implemented right, make a difference in overal
    responsiveness and speed. Even on single-processor
    machines. (Look at BeOS)

    * It does it's own input device handling, what
    should have been done by the linux kernel. Now
    virtual consoles, X, SVGA etc. all have to do
    their own handling. This is absurd, it should be
    done by the kernel, maybe in combination with a
    userspace console daemon that passes events to
    programs like the X server, but not by the
    X server itself. OK, this is more a problem of
    linux in general, and they have to work with the
    current system.
    The same goes for video-drivers, mode-setting and
    the like. That should be done by the kernel too.
    Not accelaration and drawing, only the memory
    handling. Any user can just write values to the
    videocard memory and 3D pipelines that crash most
    systems. This should be protected by the kernel,
    and it isn't.
    I regret to say that currently the standard RedHat
    combination: XFree86 with enlightenment, gnome and
    netscape crashes more often than windows 95 does.
    Let alone 98.
    Ok, so you linux itself doesn't crash, but the
    graphical system does, and people still loose all
    their work.

    * XFree86 is almost completely incommunicado if
    you try to reach them for help, or for bugreports.
    They only ever send me their standard "we got your
    message" email.
    I tries several times to get on their mailinglist,
    so I could follow their progress, but they just
    will not even answer my application.
    They are too damn closed.

    The only way I see that Linux is going to get a
    better graphical system, is when they open up,
    or if their tree is forked off by another group.

    What I would like:
    I would like to see a GGI based system, with an
    X server running on top, that implements all the
    missing features from XFree86.
    It would require a lot of people porting drivers
    from XFree86 to KGI, and a group porting XFree86
    4.0 to libGGI, fixing bugs in it, cut out all the
    accumulated slack, implement alpha channels (that
    is not in the X specifications), add antialiasing,
    make it multithreading. Decrease the memory foot-
    print. And last but not least, be very open to the
    community.

    X on GGI is the only way I see that shows real
    promise for multimedia on Linux.

    ------------------------------------------------ --------
    UNIX isn't dead, it just smells funny...
  • > Okay. So you feel that X is unstable.


    Yes.

    >I'm willing to bet that in reality, it is what
    you have done to X. >Linux/X/gnome/enlightenment hasn't crashed on me
    once. Ever. Since I installed it this August. Not Once.

    In real live I am a sysadmin at a physics
    department for Linux/Solaris. I think I know what
    I talk about. You speak only for yourself,
    and how well things work on only your box. I have a
    network full of RedHat 6.0 + updates, almost all users using
    Enlightenment + Gnome + Netscape 4.61.
    Almost all crashes I have seen are caused either
    by X (50%) or Netscape crashing taking Gnome or Enlightenment down, thereby
    closing the X-session.
    The Windows machines around here do not crash.
    People do not play games around here. Linux
    crashes quite often, using only things like
    netscape, ghostview, what people use doing
    physics. I wish it were otherwise too, but it is
    not.

    > And putting video routines into the kernel will
    improve this stability?

    Into the kernel go: only mode-setting,
    memory-management and an interface to the hardware pipelines for rendering.
    Of course NOT the X server routines doing the
    drawing and the like.
    Having the bare resource handling in the kernel
    has the enormous advantage of not having to have
    duplicate driver effort for X,
    SVGAlib, SVGATextMode, etc.
    These would simply be loadable modules.
    Userspace libraries like libGGI use ioctls to set a mode.
    Not to do acceleration and drawing. You don't need
    to, and that would be kernel-bloat yes.
    You can use memory mapping to interface the kernel
    provides. The problem is, that most cards are
    made in such a way that save registers
    , those that can be written to without crashing
    your videocard, thereby needing to reset your machine,
    cannot cleanly be separated from unsave registers.
    In that case you need a kernel space mechanism that
    makes sure only sane data goes into the accelaration pipelines.


    You can still bring X in such a state so
    that you can do nothing to switch to a console
    and bring back your machine to
    live. Ok, if you have a network,
    but most people do not have that.
    Input handling should be outside the X
    server, the X server should only
    receive events. A similacrum of raw
    keypresses if it wants to, but things like
    ctrl-alt-f1 should be caught by the kernel first,
    and all things like virtual consoles,
    X-servers, SVGAlib, etc. should receive events
    from either the kernel or a mediator daemon.

    >Are you on the GGI or Be development team or something?

    No, but I follow them closely, and am sympathetic
    to their ideas. The linux community generally has the
    wrong impression of what they try to achieve.

    I think Xfree 4.0 will suck less, a lot
    less maybe, but I'll have to see.
    Up until now for instance, it was very hard to get
    snapshots compiled, netscape would not
    display anything but empty grey screens, and
    the X team never answers request to get on
    their mailinglist, or to bugreports.
    They are just incommunicado. The GGI people are very nice,
    and do answer questions. They have achieved a lot, considering
    their numbers.

    Ah well, who am I trying to convince anyway.
    ------------------------------------------------ --------
    UNIX isn't dead, it just smells funny...
  • As far as FreeBSD goes, the new module loader will allow you to run the same of XF86 4 module on any OS, as long as it uses the same processor. So x86 Linux modules will run on FreeBSD without a recompile. Pretty cool huh!

    Is this an advantage of the ELF format or is X doing something sneaky to make this work?
  • Are you sure the "turbo switch" isn't accidently switched off? Seriously, that's what the symptoms suggest. (since modern motherboards don't really have turbo switches look for something else causing the system to run at about 5 or 8 MHz)
  • Wasn't the whole point here that you *were* noticing a considerable speed difference?
  • Anyone have any luck with Xfree86 and the Intel i810 video? I just got a new machine and X bombs on it... James F. Bickford Sys Dev Assistant Electronic Interface Support
  • Has anyone else had problems running Netscape with the snapshots? They have been pretty stable for me except when I run Netscape or Mozilla. Netscape won't follow links, doesn't render pages at all (but downloads all the data) and Mozilla -- well, it's still buggy (M13) but at least it follows links..
  • Hi Wes. I don't think building it directly into GTK would be the right thing either. Any font handling system would have to be implemented in a seperate API ( for example, freetype ), and then (insert-your-favourite-toolkit) could use that. As for "bloat", many of the kinds of applications that would need this functionality , like office suites, are already so horrendously bloated that perhaps it would not make that much difference.

    I think this needs to be implemented somewhere though. Making X antialias is difficult because this would require modifying the way X works ( and would cause possible compatibility problems ).

    BTW, antialiasing is only half of the problem. The other problem is the fact that outline files and font metrics are unavailable through the X APIs. This is essential for WYSIWYG printing, because at present, all one can do is grab bitmaps from the X server, but to print, you need the outline files associated to the fonts ( unless you're content to print at screen resolutions ), or you need to know the printer name of the font and have an entry for your font in the ghostscript Fontmap.

  • Also, different pieces of wetware (What, you suppose me to know what they are called? In a foreign language? Come on! :) are used for detecting intensity and colors. The intensity-detecting ones are much more sensitive, thus making everything seem gray when it's dark (the reflected light is below the threshold of the hue/saturation wetware). So it's really not a question of 24 bits RGB or not, but more like 24 bits HSV, with the Value part hogging most of the bits...
    Tomorrow, I will look at this analogy and cry. But tonight, it all makes sense...koffee, come hither...
  • This leaves one concern unanswered:
    What about the needed kernel support? For DRI, kernel support is added to the Linux 2.4 kernel.

    So to make use of DRI in XF86Free 4.0, what do you do when you have FreeBSD or Linux 2.2? or OS/2? Or any of the other OSes on which XFree runs?

    The module loader might be completely OS-independant, and the modules might be written for complete OS-independance, but there _are_ OS dependancies somewhere or they wouldn't be extending the Linux kernel for DRI.

    So what do you do on the other OSes?

    I'd like to know too :-)

  • I like the SunView approach. The windowing system would directly use ioctl()s to access the graphics card. Who's up for a port of THAT to Linux?

    That sounds like the same sort of thing that NT's instability is often blamed on - direct access to video hardware that runs really fast when it works. A network-transparent windowing system made a lot more sense when X was first created. At that time it was more likely that the applications wouldn't run on the machine that you were sitting at, but on some central server. Higher-powered client machines have made this less important. I had heard at one point that XFree 4 would include more efficient ways to handle local X connections to decrease the amount of overhead necessary.

  • Yes, for the voodoo3 and banshee. All the other cards (including yout tnt2) already have drivers that support window acceleration.

    If you want tot try windowed acceleration, get the dri drivers from linux.3dfx.com (which includes a XFree86 4 snapshot). Or get the drivers for you tnt2, from somewhere on nvidias site (but, like tnt2 fullscreen acceleration, window acceleration is kinda slow)
  • http://OpenUT.sourceforge.net
    http://sourceforge.net/project/?group_id=975

    They have updated drivers, including new opengl drivers, which might work better. I don't have UT, so i don't know how it works.

    Also, last time I checked, XFree86 4 does not support old glide games. Maybe it will later though.
  • Seems like most people missed this little bit tucked in the release notes:

    A DPS extension for XFree86 is currently under development. The DPS client library is now part of the XFree86 source tree; the extension code itself, however, cannot be integrated for licensing reasons and is distributed separately. For more information, please consult the DPS site at SourceForge [sourceforge.net].

    Unfortunately the licensing is a bit messy - they are based off the most recent Aladdin GhostScript. But it's still cool to see it's in the works.
  • are there gonna be any improvements other than additional hardware support? more speed, full screen game play or something?
  • Your uneducated guess is a good one.

    RH 7.0 will almost definitely be the Kernel 2.4/XF86 4.0 release (possibly KDE 2 and/or GNOME 1.2 as well).
  • I have the same problem with my voodoo2 when UT freezes. The easiest way (for me) to fix this is simply to restart UT. Either telnet in from another box and start it, or switch VTs (it is switching, even though you can't see it) and start it. The problem is that when it crashes, UT doesn't reset the voodoo2 to accept signals from the passthrough cable. The other option is to plug your monitor into your 2d card instead of the voodoo2.

  • NEWSFLASH: You don't have to read all the stuff posted on Slashdot. If you see an uninteresting comment, feel free not to read it. In any case, don't post crap like this.

    Slashdot has headlines. About 8 headlines per page to be more precise. What a great place to post duplicates.
    --
    Here is the result of your Slashdot Purity Test.
  • So, if Rupert Murdoch decided to run stories exalting, say, Pat Buchanan as the ideal Presidential candidate and run mud-slinging stories on all the others, you'd have no problem with that because "Rupe wanted to and it's his multi-media conglomerate"?
    --
    Here is the result of your Slashdot Purity Test.
  • I'm not saying it should be illegal for Murdoch to broadcast what he wants. Like you, "...I recognize his right to run his business as he sees fit". Also like you, presumably, I know that the media wields a great deal of power and there is responsibility that goes with this power. When that responsibility is abused, I complain. Would you deny me the right to make complaints when I want?

    In other words, take your own advice: when you see someone has written another comment you don't want to read, instead of repeating the tired, ass-kissing adage "Let Rob do what he wants", just think to yourself "Let Poster X do what he wants--which is apparently complaining to Rob."

    There, look what you've done--you've made me violate my own advice.
    --
    Here is the result of your Slashdot Purity Test.
  • I am interested in upgrading my video card and have had a hard time bringing all the fragmented information about what cards will have fairly complete Linux support. Does anyone have a handle on this?
    What cards will/do have hardware 3D acceleration and support similar to what they do have under windows? What are people using that they are happy with? Or please point me in the direction of some good information that can help me make an informed choice.

    -Thanx
  • Obviously, I'm not savvy to the details of the /.
    purchase, but I'm not sure that it is Rob's site anymore. At least not technically.

    Regardless, this story does seem appropriate. And as Rob is still the chief editor (?) of /., it doesn't matter what you or I, or the Troll's think.

    However, I do think that story moderation might be in order, if for nothing else that to allow the PTB to assess their audience. That just makes good business sense.
  • Does MacOS let you use those screens as one logical screen? Multiple screens with multiple sizes and color depths are supported (in various ways), they're just not as convenient as Xinerama.
  • Why not just dump X and get a decent imaging model as the new standard?

    NextStep, OSX, etc. all used the Postscript model, and they get a good part of the flexibility on the display side from this.

    Why not just get Ghostscript up and running, and bolt the display stuff onto that??
    John
  • Well, RedHat 7.0 will be itself a "point oh" release, so it makes sense for it to include all the new major version numbers. Those who fear "point oh" releases will wait for RedHat 7.1...

    --

  • I installed 3.9.17 a while back and everything worked just dandy.. except netscape 4.7..
    It would fetch a webpage but wouldnt display it, and i could look at it via view>src but thats about it.. I guessed it was cuz it was statically linked against some xlib or something like that.. Any ideas?
  • Quadruple head support. But this only works if you have four Matrox cards or two G400s.

    I have only one video card, but I've decided to do twice as well as Zaphod Beeblebrox, and I now have four heads. Can I use the quadruple-head support?

  • See section 2.1 of the 3.9.17 relnotes [xfree86.org]
    --
  • This isn't just any old release, this is the last XFree before 4.0, one of the most eagerly awaited releases in recent times. Even if the article had said nothing but "XFree86 is now expected in early March", that would have been news for nerds, stuff that matters.
    --
  • They're doing something sneaky. X uses its own module loader instead of relying on the OS. The same modules will work on all OS's for the same architecture.
    --
  • I had exactly the same problem that you're describing. The solution I had at the time was to disable Javascript (don't ask me why this fixed it, as I have absolutely no idea).

    3.9.18 fixes the 'invisible page' problem.
  • So XFree86 4 is going to be released with virtually no cards supported (for 3D) then, as we are talking about a few weeks to release. While the Utah glx project has excellent hardware support for a wide range of cards, including developing the agpgart kernel module, in less time with less funding. Why? An open development process is the obvious answer. Precision Insight provides companies with a driver development model that they understand, but they and XFree86 need to open up.

    They have different goals. The XFree team is trying to put out an X server. A couple sample implementations to prove their design is correct is enough. They don't have to support many cards because the support can be written after release.

    The Utah-GLX project is trying to write drivers for 3D video cards using GLX. It's not surprising that they've gotten more drivers out than XFree has.

    When XFree86 4.0 is released, the Utah team can port their drivers. There's no reason to double the effort to write 3D drivers.
  • I would suspect so. RH 6.2 is available in beta, so I doubt they'll put XFree86 4.0 into 6.2 My uneducated guess is that the 7.0 release will contain kernel 2.4 and XFree86 4.0.
  • Apparently my graphics card (an 8MB Matrox G200) will have overlay support when running in 32bpp (I usually run it in 1024x768x32 anyway). Which sounds very nice, but for one thing. What the hell are overlays? They sound interesting - is it for overlaying, say, video from a card or MPEG player, or for something completely different?

    Overall, XFree86 4.0 looks pretty good - the older version I'm using storms along at 2D stuff and has 3D acceleration thanks to Utah GLX; 4.0 will probably be even better.

    Ford Prefect
  • You are right about the way Xfonts work. There are some ways this can be addressed with technologies such as Display Postscript. IMO, the best way to handle this is bypass the X font handling model altogether and write an improved font management model into the toolkits. The "improved" model should include functionality to make outline files available ( if they are available ). This is what display postscript does. There is already the technology in place to antialias both type1 and truetype fonts ( freetype ), the problem is all in the X font system.

  • Yep, true type fonts are supported ( READ THE RELEASE NOTES ). In fact in Redhat, this is true as of 6.0, with the xfs server shipping with xfsft patches. However, it won't antialias just yet.

  • From the FTP site:

    ftp://ftp.xfree86.org/pub/XFree86/snapshots/3.9. 18/00README

    This directory contains the XFree86 3.9.18 snapshot release.
    The contents are as follows:

    doc/ Documentation
    doc/HTML/ Documentation in HTML format
    fixes/ Fixes for serious problems found after this snapshot was released
    patches/ Patches for updating the previous release to this one
    source/ Source tarballs for this snapshot release

    NOTE: The 3.9.18 distribution is still being put into place, so not all
    of the above are there yet.

    22 Feb 2000
  • You are right. I am a bonehead. I got so excited my fingers kept flying but my brain disengaged.
    What I meant to say was "a supernovicular explosion of features".
  • NEWSFLASH: You don't have to read all the stuff posted on Slashdot. If you see an uninteresting story, feel free not to follow the link. In any case, don't post crap like this.

    Freshmeat has comments. About two comments per program to be more precise. What a lively discussion.

  • That's probably because, officially, there isn't 3.3.6 for slink. Some have been made but they aren't part of the official slink distribution, so your mileage may vary. XFree86 3.3.6 in potato, on the other hand, is just fine from my experience.
  • Freshmeat is for downloading the shit, /. is for bitching about it, flaming, trolling, zealotry, my-os-is-better, "i submitted this last week", and "Linux!" 'No! BSD!'
  • What about 3DLabs! Does the X world think 3D revolves around 3dfx and voodoo?
  • Some hardware does alpha blending, much like some hardware accelerates sprites.

    More accurately, in the final digital-to-analog conversion hardware those 8 bits aren't used for anything (although they could be put to very good use, if the monitors were of sufficiently high quality: the human eye can detect very faint differences in intensity, more than the 256 possible levels of greyshade in a 24-bit pixel, though the human eye is not really sensitive enough to distinguish between all the possible colors of a 24-bit pixel, so the extra byte could be used to create higher intensity resolution, so you had 16-bits of intensity, 8 implicit in the RGB and 8 explicit). In the image composition acceleration hardware, the extra byte may or may not be used.

    You can't have a transparent pixel on your monitor, but you can sometimes have a transparent pixel in your video memory.
  • That's not entirely true. X does use it's own loader, contributed by Metroworks (I think). However some modules still require certain kernel support, such as the fbdev driver. So a subset of the modules will work on any architecture, but not all of them will work everywhere.
  • As of now, Precision insight is working on DRI for 3dfx and ATI 128 cards, for inclusion in XF86 4.

    The Utah GLX project has working under the XF85 3.3.X series writing drivers for Matrox, ATI Rage, S3 Virge, Nvidia, and i810 cards, outside the DRI framework. These will need to be converted to DRI to be included XFree86 4.

    So XFree86 4 is going to be released with virtually no cards supported (for 3D) then, as we are talking about a few weeks to release. While the Utah glx project has excellent hardware support for a wide range of cards, including developing the agpgart kernel module, in less time with less funding. Why? An open development process is the obvious answer. Precision Insight provides companies with a driver development model that they understand, but they and XFree86 need to open up.
  • Maybe it's just me, but I've noticed that whenever I try to start up X I get a syslog'd error about MTRR and mem overlapping (32mb vs 64mb at the 0xe0000000...point, where the vid card maps its ram). I have a voodoo3/3000. Anyone else have this problem, and will something as simple as disabling MTRR in the kernel fix this?
  • "Quantum" means that the step is indivisible, not that it's large or small.

    Stairs have quantum steps of about 8". My old analog radio receiver had a continuous tuning circuit, but my digital radio receiver has quantum steps of 200 kHz (iirc).

    The dictionary definition of "quantum leap" makes sense in that it describes a discontinuous change. By their nature, discontinuous changes are abrupt and can't be broken down into smaller steps. The "dramatic advance" follows from the fact that most human-scale continuous changes are actually the result of many small discrete changes, so they're drawing a distinction by specifying this change is large.
  • Summary of new features in 3.9.18 compared with 3.9.17: http://www.xfree86.org/3.9.18/RELNOT ES1.html [xfree86.org]

    Summary of new features in 3.9.17 compared with 3.9.16: http://www.xfree86.org/3.9.18/RELNOT ES2.html [xfree86.org]

    Summary of new features in 3.9.16 compared with 3.9.15: http://www.xfree86.org/3.9.18/RELNOT ES3.html [xfree86.org]

    Chris Hagar

  • In posting this comment, all my moderations for this story have been undone, so. Well, if anyone wants to moderate this up like I was going to, please do so. :)

    Chris Hagar
  • I use a quick hack for it: Copy old (3.3.x) lib of X11 to somewhere else (lets say /opt/X11/lib). Now do: export LD_LIBRARY_PATH=/opt/X11/lib netscape this works mostly fine here, .17 only had some minor graphical glitches with netscape. regards, Michael
  • Just so you know: PI is also working on drivers for Intel (the i810) and Matrox (G200/G400). According to Daryll Strauss they should all be out by the end of the second quarter, even if they aren't included in XFree86 4.0.

    Adam
  • When their server couldn't talk to be, it gave me the following list of mirror sites. Typos introduced into the list in converting it to HTML are mostly my fault. However, Slashdot is fighting me on the lists a little bit, introducing spaces in my end tags.


    US



    Europe



  • ftp://ftp.xfree86.org/pu b/XFree86/snapshots/3.9.17/binaries/ [xfree86.org]

    has binaries for
    FreeBSD-2.2.x and 3.x
    NetBSD-1.3
    Linux on Alpha/Intel, glibc only.
    Solaris

    They're .tgz packages. tar -zxf 'em from root. If you have a copy of Slackware pkgtool floating around you can use that. Otherwise, there are a number of small utils that will convert them to .rpm for you.

    If there isn't one for you (eg, you still have a libc system) download the source. It's a usually a simple make World && make install && make install.man. Be warned, on a K6-2 500 the process took a few hours. Oh yeah.. The funny looking INSTALL.TXT file is actually nroff formatted. 'nroff INSTALL.TXT | less' works.
  • I've been using 3.9.17 for a while, and its at least as stable as 3.3.2 was (for me ;.). Except for the occasional queer behavior from Xinerama, which 99% of end-users aren't going to touch anyway, I'd give it a thumbs up to make it into the RH 6.2 distro.
  • Actually the human eye can see much more than 24 bit. Consider this, 24 bit equals 8 bits per red, green and blue component. So that means you only have 256 distinct steps between pure white and pure black if you make a gradient.

    Even on a monitor this can be noticeable but it is really a problem with graphics made for cinema or hi definition television. In these cases they often use 12 bit per rgb component (36 bit colour!) to avoid obvious banding effects.

    So the human eye only seeing 24 bit is, like the supposed 30 frames per second thing, a myth.
  • In the announcement link the release notes link is broken pointing to a non existant document. So I guess I will ask this. What exactly are the real improvements? Does this affect anyone except people who are running new stuff? Better optimizations for older stuff? Less memory waste?
  • FYI, I've heard that the XFree86 3.3.6 debs for stable (and others in the series) are quite unstable and buggy (and this is from the official Debian X maintainer, Branden Robinson). I've never used them - but I figured out might want to know.

    Also, why not use unstable? It can be a bit annoying sometimes (when something breaks, and fscks with dpkg), but you get access to up to the second software, the latest packages and dpkg enhancements, and a chance to help out Debian (by reporting any bugs you find in unstable). I've used it for quite a while now, without any major problems.

  • Just in case this was not meant as a joke: enlightenment, blackbox and all the other existing GUIs run on top of XFree86. They're by no means replacing it.

    If you'd like to replace XFree86, maybe go for framebuffer devices, svgalib or GGI.
  • <p>The I810 needs some kernel patches to work properly.
    <p>You might want to try getting the kernel and XFree86 packages from the current Red Hat Linux 6.2 beta (<a href="ftp://ftp.redhat.com/pub/redhat-6.2beta/i386 ">ftp://ftp.redhat.com/pub/redhat-6.2bet a/i386/</a>) - we're now supporting the i810 chipset.
  • Many thanks to the XFree team for coming one step closer to a major milestone.

    The thing to look for now is 3D chip OEMs following through on their promises to make DRI drivers available.

    NVidia's GLX implementation wasn't much good to me, and I wish I had kept my Voodoo2 lying around when I replaced my video card over the summer. X4 w/ DRI is the first step for me in finally going Linux full time.

    The companies we all support with our hard earned bucks must support us with their commitments, and alternative OS drivers. (Sorry to refer to Linux in this respect. I sure don't view Linux as an alternative, but many people have yet to clue in. Any PHB's listening?)

    Make your voices heard, and make sure that companies don't merely capitalize on promises without following through. Patience and mutual understanding are important virtues for anyone involved in a movement to promote awareness. Remember that as we all work together to make Linux better than ever, and add this piece to the puzzle.


  • It's a rarely used feature but that accursed AccelX bunch claims to have g400 dual head (dual monitor) support, and they lord it all over XFree on their website.
  • This is excellent. I wonder if there is NVidia DRI, or if DRI still only works w/ Matrox/3DFx cards.
    Does anyone know if DRI will work under FreeBSD as well as Linux? Or is that kind of low level hardware access kernel specific?


    He who knows not, and knows he knows not is a wise man
  • xinerama DOES allow different screen sizes. and each one can be resized ON THE FLY. can macOS do that?

    you can't [currently] have different bit/color depths yet. but I think that's an 'overlay' function that is coming...

    otoh, can macOS allow different window managers? different look/feel themes? macOS was the most strict UI I've ever seen. just like the original Ford car - any color you want - as long as its black.

    --

  • I figured that if I didn't bring this up, someone else would (as this comment seems to be posted to every Xfree story on Slashdot).

    Most of us are looking forward to antialiasing for fonts, somehow. Unfortunately, the server returns fonts as a 2-dimensional binary array (if I'm understanding things correctly). That's means pixels are either "on" or "off" (no greys).. So, it would seem that antialiasing would not be possible without a major rewrite of the API or something.

    That's my question, though. Is a rewrite of the API likely? Or, do you think that a competing display technology [ggi-project.org] to XFree taking hold would be more probable?

    Alex Bischoff
    ---

  • Re:can someone explain using small words? (Score:3)

    by drig ( 5119 ) on Wednesday February 23, 2000 @06:47AM (#1253051) Homepage Journal
    Would anyone be willing to explain what these great new features are, and what they will do for us?

    DRI - Direct Rendering Infrastructure
    Basically, the DRI allows a 3D application (game, most likely) to talk directly to the video card. Currently, GLX is a network protocol, and so all 3D requests go over the network (this is a simplification).

    Multi-Head/Xinerama
    The ability to use 2 video cards at the same time. Classic multi-head means 2 X sessions at the same time. Xinerama is an extension to allow you to have 1 session that splits across 2 screens. Very cool.

    Unified Device Drivers
    In previous versions of XFree, you'd have to write a driver for each video card and then port it to each platform. So, Matrox (for instance) didn't makr XFree drivers. They'd have to make it for Linux and port it to FreeBSD and Solaris x86 and OS/2. Porting requires significant effort. Now, they write 1 driver and it works on all x86 machines.

    Better Mouse Support
    These new fangled mice have all sorts of buttons on them. Mine has 3 buttons and 2 scroll wheels (each scroll wheel is seen as 2 buttons...one pressed when you scroll up and one on down). XFree 3.3.x only supported 5 buttons (and thus my second scroll wheel doesn't work). XFree 4.0 supports unlimited numbers.

    General Re-write
    The XFree guys have been at it a long time now. So, they're taking this opportunity to rewrite some portions of their code. It's supposed to be faster and use less memory.

  • Re:"Quantum leap" (Score:3)

    by crumley ( 12964 ) on Tuesday February 22, 2000 @09:56AM (#1253052) Homepage Journal
    A "quantum leap" forward is, literally, a miniscule advance.

    Uhm, no. A "quantum leap" is a big advance. From Meriam-Webster Online:

    Main Entry: quantum leap
    Function: noun
    Date: 1956
    : an abrupt change, sudden increase, or dramatic advance

    It does derive from quantum mechanics. I think it comes from the idea that energy levels are quantized, so that to move from one to another you have to have some minimum energy jump. So the step forward your talking about is not a minuscule step, but a a more revolutionary step forward.

  • Re:Gee.. (Score:3)

    by fusion94 ( 19221 ) on Tuesday February 22, 2000 @09:36AM (#1253053) Homepage
    Another quick mirror is:

    ftp://download.sourceforge.net/pub/mirrors/XFree 86/snapshots/3.9.18/

    http://download.sourceforge.net/mirrors/XFree86/ snapshots/3.9.18/

  • They are putting it all into the toolkits (Score:3)

    by nikolas ( 35223 ) on Tuesday February 22, 2000 @10:56AM (#1253054)
    Well, people seem to like stuffing everything that they are missing in their windowing system into their toolkits nowadays, sans fixing the windowing system, which is not the way to go, imho.

    The ggi-project on the other hand basically is a portable graphics library, not a windowing system, which wont help unless someone built a windowing system on top of it.

    Thats what the berlin folks are doing, but their project seems to be very (very, veryvery) ambitious. To the point that I fear they will not be able to attract new developers because of their lack of a production (sort of) system.

    GGI on the other hand seems to be out of the game kernel-wise and is (partly) still suffering from "nobody recognizes my work, I dont want to be a part of society"-attitude. All this is really a shame.

    I wish the fbdev- developers would get more support (and 3D accel support in the kernel that is not made solely for X) so that people can get together and finally build a modern windowing system without having to think about graphics libs and devices first. They have to think about that enough anyway.

  • Re:Debian stable == proven (Score:3)

    by coyote-san ( 38515 ) on Wednesday February 23, 2000 @07:39AM (#1253055)
    No, Debian stable = proven packages. It may not be sexy, but it means you aren't constantly mucking with the system while others are muttering that maybe they should go back to good old reliable MS Windows.

    And if you really want to run the cutting edge, you can always run unstable.

  • Gee.. (Score:3)

    by technos ( 73414 ) on Tuesday February 22, 2000 @08:41AM (#1253056) Homepage Journal
    Gee, I could swear I submitted this late yesterday when the file tree changed..

    Anyway, the source can be had here [xfree86.org], and you really should read the release notes here [xfree86.org] once they appear.

    No real info is available on what exactly is new in 18: Any XFree developers here that can fill us in?

  • Re:RPMS? (Score:3)

    by technos ( 73414 ) on Tuesday February 22, 2000 @11:20AM (#1253057) Homepage Journal
    Yes, there are usually binary-only RPMs available for the major supported platforms (Solaris, *BSD-x86, Linux-x86/alpha, etc) within a week or so.. I'd be terribly surprised if it took much longer than that

  • Re:Wow! That was Fast! (Score:3)

    by bero-rh ( 98815 ) <bero&redhat,com> on Tuesday February 22, 2000 @09:13AM (#1253058) Homepage
    Is Redhat waiting on this so they can include the "four point oh" in the features list on the box?

    No. Have a look at the current beta - some packages will change (some have changed already), but there won't be any major changes such as moving to XFree86 4.0, Kernel 2.4, glibc 2.2, KDE 2.0, GNOME 1.2 or whatever else is ahead.

    XFree86 will definitely bring a lot of good things, but also some breakage because of library and header changes. Anyone shipping 4.0 as soon as it's released (without fixing up some applications or waiting for them to be fixed) is setting himself up for some trouble.

  • Experiences so far.. (Score:4)

    by Anonymous Coward on Tuesday February 22, 2000 @09:16AM (#1253059)
    I just built this on an OpenBSD box a few hours ago. Overall it was a smooth process except for one hitch which might be a problem for those who use OpenBSD.

    On OpenBSD in the file Xlocale.h you have to add:

    #define X_NOT_STDC_ENV

    to get it to properly compile. Hopefully this helps.

    Don't hate me because I'm a troll.

  • Re:Overlay Support (Score:4)

    by drig ( 5119 ) on Tuesday February 22, 2000 @09:17AM (#1253060) Homepage Journal
    If you like to run with lots of colors (who doesn't?), but still need support for 8bpp screens, overlays are for you. It works by using 32 bits, but running in 24bpp mode. The remaining 8 bits are used to support a 8bpp mode. So, you can still run 8bpp apps (FrameMaker is one. I think xfishtank is also one, unless it's been updated) on a high-color screen. You lose some of the finer color control that's useful for graphics production. But, 24bpp is generally more than the human eye can perceive.

  • Re:Best supported cards? (Score:4)

    by adamk ( 67660 ) on Tuesday February 22, 2000 @10:00AM (#1253061)

    Note: I'm speaking as an individual who has read quite a bit on 3D support under linux and who has used the following 3d chips under linux (not as a developer): Savage4, ATI Rage 128, TNT2, 3dfx.

    Currently, the best supported 3D cards under linux are 3dfx and Matrox. 3dfx is probably better supported at the moment. By mid-year Precision Insight plans on having DRI drivers for 3dfx (already available from cvs), Matrox (G200/G400), ATI (Rage 128), and Intel (I810). nVidia should be releasing drivers in the next few months for their line of 3D cards, although the impression I've gotten is that they won't be using DRI (apparently they or SGI didn't feel that DRI was the most appropriate means of doing accelerated 3d for nVidia's cards).

    Utah-GLX already supports hardware acceleration for ATI Rage Pro, Matrox, nVidia, S3 Virge, and probably something else that I'm forgetting. However, Utah-GLX doesn't use the Direct Rendering Infrastructure.

  • 3.9.16 was great for Xinerama; will try current (Score:4)

    by TheGratefulNet ( 143330 ) on Tuesday February 22, 2000 @09:42AM (#1253062)
    I run a pair of matrox (agp,pci) cards in Xinerama mode. let me tell you - its AMAZING how much you can get attached to 2 physical monitors. and not only that, but dragging the windows across phys screen boundaries is just awesome.

    when I was at sgi, we had 2 kinds of dual-screen xservers. one was the classical dualhead setup (running on an Octane). you had a :0 and a :1 screen. and only the mouse would travel between them. for each client, you had to have their 'default' set to :0 or :1 to get a window on that screen, or specifically ask for it at launch time. after it was bound to a screen, there was no easy way to move it over.

    then there was the hybrid hack that the O2 systems used. it combined each head into a virtual contiguous screen (ie, there was only a :0 screen). you could bind the 2nd display either below the first one or along side of it. running xdpyinfo would show a single big screen and not two. the problem is that window managers didn't deal well with this arrangement. and you'd end up with mouse problems and dragging issues when trying to keep windows inside a screen border. I hated it - it was an aweful hack.

    with xinerama, you have the best of both, sort of. you don't have a :1 but you do have a sane setup that respects the vertical screen edges, yet dragging can occur seamlessly horizontally.

    and btw, if you want classical dualhead X, you can choose to startx WITHOUT xinerama mode. that is, if you really do want a :0 and a :1 screen device.

    for the price of 2 used matrox cards ($50/ea at current used prices), a dualhead setup CANNOT BE BEAT. I run the same dual head setup at work and at home. its VERY addictive ;-)

    --

  • Re:Please don't include XFree 4.0 in Redhat 6.2 !! (Score:4)

    by daemonc ( 145175 ) on Tuesday February 22, 2000 @09:01AM (#1253063)
    My prediction: Redhat 6.2 with Xfree86 3.3.6, all the current stuff. Then in late summer/ early fall , Redhat 7.0 with Xfree86 4.x, and a 2.4 kernel (I thought the DRI in Xfree86 4.0 needed some special kenel modules anyway). Also should have the upcoming version of Gnome that probably won't make it into 6.2, also expect to see a Redhat branded Mozilla in there. In my opion it is going to rock.

  • Really, Freshmeat / Slashdot crossover is OK. (Score:5)

    by Poe ( 12710 ) on Tuesday February 22, 2000 @09:11AM (#1253064) Homepage
    Slashdot = News for Nerds. Stuff that matters.
    Freshmeat = New cool open source related software.
    Not all of the new software is news, not all of the news is related to new software. But having the crossover in both places is good. Anyone who actually reads freshmeat can tell you, it's easy to let an important program get lost in the shuffle. There are now rougly 60 new items on freshmeat daily. As someone who reads both, I am glad to have the redundancy.

    I'm so excited about XFree86 4.0 any new info should be written on the moon and stars. As I understand it, this will be a quantum leap forward in Gaming, Graphics and usability for Linux. Goodness knows we could use it.

  • Re:One step closer to 3D in Linux (FBSD?) (Score:5)

    by bbk ( 33798 ) on Tuesday February 22, 2000 @08:53AM (#1253065) Homepage
    As of now, Precision insight is working on DRI for 3dfx and ATI 128 cards, for inclusion in XF86 4.

    The Utah GLX project has working under the XF85 3.3.X series writing drivers for Matrox, ATI Rage, S3 Virge, Nvidia, and i810 cards, outside the DRI framework. These will need to be converted to DRI to be included XFree86 4.

    As far as FreeBSD goes, the new module loader will allow you to run the same of XF86 4 module on any OS, as long as it uses the same processor. So x86 Linux modules will run on FreeBSD without a recompile. Pretty cool huh!

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close