Slashdot Mirror

Sure. It's a simple (stupid) reason...

Movies are released in different areas at different times. For example, a movie may be released to DVD in the US just as it hits the screens in Oz. But the industry doesn't like people being able to mail-order a US DVD from Oz and see a movie before they've cashed in on the box office sales.

The error(s) in their logic... how much is a movie ticket? How much is the DVD? Would you never go to a theater to see the movie just because you own the DVD?

Personally, I spend way more on videos (tapes/DVDs) than I do on movie tickets. And I often will see a movie in a theater even after I own the video -- not many people have a "home theater".

For the record, region coding is NOT "copy protection" as such it's not illegal in that sense. If anything, defeating the region coding would be a breach of the EULA for the software and/or hardware.

As was mentioned on the LiVid mailing list, it's not the home user pimping gigs of MPEG files that MPAA should be worried about. It's the Asian copy houses capable of de-compositing a pressed CD to make a master and then spit out thousands of copies. [* ] Correct me if anyone's tried this, but the home user has no way of making a DVD-ROM playable in a stand-alone DVD player. I don't know of any that will read a DVD-RAM. (Disclaimer: I've not wasted my money on a DVD-RAM, yet.)

Well, I'll bite. Firstly, Nvidea, the Riva ppl, are not open. They've simply released a driver with no specs, making peer improvement difficult at best. Pity =(

Matrox on the other hand, is one of the companies that has helped get device drivers to a level where they are today, by releasing specs since Way Back When (tm) in the days of the orginal Millenium.

Now, the GLX group ( Link) has had specs for the ATI cards for a lil while now, and even has a preliminary driver in the works with DMA and everything. Anyone with a Matrox G200, G400, Nvidea card or ATI card should stop in here, and lend a hand if they can.

Anyway, insert a cheer here. For every company releasing specs, it sets a precedent for others to do the same!

Not very. Granted they have an X server you can download and the glx.so module which lets you play q3test, they havn't released specs for their cards so that stuff like agp support, or even dma texture copies can be done. This means that your framerate in linux is about half of what you get on Windoze (I think, don't have windoze on my machine).

They have released a kernel mod that is supposed to be an interface (they call it a resource manager) to the function I mentioned above, but a) the important code is preprocessed, b) it's for 2.0.34 not 2.2.x and I can't get it to compile even for 2.0.34, c) this is not the way graphics are handled by any other card. This really should be a library or something like that.

The other real open graphics card maker is Matrox. They have released an API that is being used in the glx project . They are getting much higher framerates on a G200 than I get on my TNT2.

From all that I can gather this also means no one as started to work on the XFree 4.0 DRI implementation for Riva cards.

Hopefully this news will get Riva to open up a little more.

Perhaps the demand for a low-end Unix Graphics Workstation with Linux and a GeForce 256 to replace some SGI's will get them moving.
--

It's been a while since I first read that someone was working on GLX drivers for the Rage Pro based on released ATI specs. For more up to date info, I suggest people to check: GLX.

Question for John C.:
I've been very happy to see that the project to support various 3D hardware on Linux that you have been cooperating on has progressed nicely in the last few months. Now that you have had experience writing OpenGL drivers with the Open Source model, do you think that the success the project will influence companies to release full specifications for their hardware and even open up development of their drivers? Or do you expect that the current practice of keeping programming information secret will continue into the foreseeable future?

As for software decoders, the ones for Windows don't seem very optimized. And Linux decoders are still being worked on. For those of you interested in Linux DVD, I recommend that you check out the LiViD Project and the Linux TV site.

Could anybody with more insight please explain to me (and probably to others, too) what _fundamental_technical_ obstacles exist which prevent you from building a nc-server network with one big and several small standart pc's and your favorite linux distribution?
I mean Xfree, nfs/code etc, nis/kerberos, telnet/ssh. Not every package mentioned is perfect, but I want to know about fundamental problems. Isn't - in this context - the "network computer" just a buzzword? Take a large ramdisk and boot over the network using something as nilo..
Or don't use the all or nothing approach and use a local harddisc + apps over network.

That would be Omega Central.

Unfortunately it locks up the X server here with the GLX module loaded for my G200 card (http://glx.on.openprojects.net/). Any have better luck? perfly is trying to draw in the root window. -adnans

I know. (Note: I submit patches occasionally and maintain the FreeBSD port, cf the FAQ) :-)

When it officially ships as a GLX driver, I honestly think it will make Linux look good.

I am quite sure the Matrox and eventually the nvidia hardware device driver will stay, the rest (like the GLX implemention) might be replaced by sources from SGI. We might eventually have to wait until XFree86 4, before Precision Insight puts all cards on the table and evaluation starts. When I remember correctly, they announced support for a whole bunch of cards, but were not willing to reveal which ones.

In fact SuSE does some 3d work too. Their scheme for MLX looks quite sophisticated (look here) but I don't know what is going on there right now. MLX was announced together with support for GLINT and Permedia chips.

Alas the only ones I noticed being active lately were the openprojects GLX group and the PI folks. That is why I said I doubt that the new SuSE drivers feature 3d.

My Diamond Viper 500 (TNT chipset) works fine with the glx.on.openprojects.net RIVA driver on my FreeBSD system. (The glx stuff is pretty much portable between Linux and FreeBSD)

So I am surprised that you had no luck. Try again!

Ha! You'll be getting much more than that eventually!
Read here for good news and here for bad news (well, at least for you).

Ha! You'll be getting much more than that eventually!
Read here for good news and here for bad news (well, at least for you).

--

--

Try http://www.freebsd.org/~3d/

It's a few days out of date (No 3.3.5 yet), but I'm sure the avid gamers will figure it out... Or look at http://glx.on.openprojects.net/

Like most third party software, the source code used for FreeBSD (the other BSD's) and Linux is the same, and so the feature set is pretty much the same.

Regards,
-Jeremy

Nick

1. Get Mesa 3.0 (cvs wan't working last I tried), compile, install.
2. Get latest cvs of glx. compile install.
3. replace link from libMesaGL.so.3 to libMesaGL.3.0 with link from libMesaGL.so.3 to libGL.1.0.
4. Make sure your X config has both glx.so in the modules list and a 640x480 setup (the latter got me for a while).
5. Run q3test.
6. If you're anything like me, get slaughtered:)

BTW: FAQ

Not id per se, but J.Carmack personally.
To see it yourself, go to the g200-dev mailing list. He is a very keen participant of this list. Incredible, I wonder how he gets the time, but anyway, he seems to be really cool.

1600's Calvinist totalitarians (Pilgrims on a journey my ass) escape the wrath of Catholic totalitarians

Salem. Nuff said.

1770's Unpopular Declaration of Independence discussed behind closed doors. All who wanted to be in had to sign. This meant if they were found or the war lost they would be shot.

Big debate on women voting too.

'Course it wasn't too long before we pulled a Columbus on Indians, Mexico.

So don't be surprised. We need a more direct response to this.

When Germany ordered Jews to wear yellow markers, all of Denmark wore them without even thinking twice. It was obvious what they had to do.

So start encrypting long repetitititions of "Mom, I'm at the store. I'll bring my commie friends home tonight."

Check out

Freenet

Ompages

Link Farm

They're trying to reinvent the Earth and conquer it before people get their rightful share. If you really don't want to see pedophiles on the net, your best bet is to claim some part of the net and get over your fears. Otherwise we're guaranteed to see the net auctioned off to superpowers and rampant with crime. There's too much power in it for the assholes to pass up.


Go see Senate on the net and House on th net

On another note, anyone who knows about DVD and in particular the Matrox DVD add-on (based on the Zoran chipset) please go to LiViD. We need help.

Nick

Both the nVidia TNT[2] and Matrox G200/G400 efforts were mentioned during the BOF as already existing open efforts that people could get involved in.

We have our own load (based on Red Hat) that has some kernel tweaks provided by our engineers to optimize performance on our systems. The only way you can get this version of Linux is with a VA system.

Ouch, you make that sound like a GPL violation! Before anybody flames them, they do appear to have the modified kernels on ftp.varesearch.com. Maybe you should have left off that last sentence?

I'd also like to say that VA has been doing great things to support the community. They're supporting a number of developers full time, and the services they provide through on.openprojects.net are just wonderful. Way to go, guys!

It is my observation that on most open-source projects there are a very small number of core developers (often friends in real life), but alot of users who submit bug reports and pester about the next release. Often the process of delegation can be more time-consuming than just doing it yourself. They say that human brains can only really cope with working in groups of up to 7 people anyway. Having to work over the Internet makes this even more difficult.

--

http://lists .openprojects.net/pipermail/g200-dev/1999-July/002 304.html

Personally, I think it's wonderful. My most extensive experience with it has been in the glx project, and it's worked very well. Not being a professional programmer, it's the most sophisticated system I've every used. From talking to some of my friends, I understand it has some advantages over a lot of the commercial offerings, so we may not be missing much. :) I also use it to keep track of the data and analysis routines for my scientific work.

That said, there are lots of problems. It's not been terribly stable in my experience. It has poor support for binary files. Administration isn't fun (or easy) and it's difficult to set up securely. It's not very smart: particularly glaring ommisions are that you can't remove directories once they're added to the source tree (!), and moving files around is a pain. The notion of "code branches" could be more powerful and easier to use. (This is probably the part linus objected to--I couldn't imagine trying to track all the kernel patches that way. maybe with a gui front-end and database to keep track of the options... :) It's not easy to perform clean backups or mirrors either, and the command line options are neither elegant nor consistent. Oh yes, and it could be faster. That's my personal list so far.

Basically, it's a hack on top of rcs, and it's starting to show. It could probably benifit from a complete rewrite in the next year or so, with the addition of things like a security model and support for distributed (and mirrored) repositories. bitkeeper is something like this, but not free software. prcs is another, gpl'd, attempt headed by Josh MacDonald, author of xdelta; there's no client/server for it yet, though. Personally, I'd like to see a cross between cvs, an eternity server, and Debian's apt package tool. :)

Nevertheless, I think it works fine for medium sized projects and really helps facilitate/speed up internet-based development. Beats mailing patches around!

Personally, I think it's wonderful. My most extensive experience with it has been in the glx project, and it's worked very well. Not being a professional programmer, it's the most sophisticated system I've every used. From talking to some of my friends, I understand it has some advantages over a lot of the commercial offerings, so we may not be missing much. :) I also use it to keep track of the data and analysis routines for my scientific work.

That said, there are lots of problems. It's not been terribly stable in my experience. It has poor support for binary files. Administration isn't fun (or easy) and it's difficult to set up securely. It's not very smart: particularly glaring ommisions are that you can't remove directories once they're added to the source tree (!), and moving files around is a pain. The notion of "code branches" could be more powerful (and easier to use). It's not easy to perform clean backups or mirrors either, and the command line options are neither elegant nor consistent. That's my personal list so far. :)

Basically, it's a hack on top of rcs, and it's starting to show. It could probably benifit from a complete rewrite in the next year or so, with the addition of things like a security model and support for distributed (and mirrored) repositories. bitkeeper is something like this, but not free software. prcs is another, gpl'd, attempt headed by Josh MacDonald, author of xdelta; there's no client/server for it yet, though.

Checkout glx.on.openprojects.net if you're interested in the development drivers. There's cvs source and binary packages available.

The drivers provide hardware-accelerated OpenGL support for the Matrox G200 (and maybe G400) cards and the nvidia riva series under linux and other unix-ish systems using Xfree 3.3. They're still under heavy development, but quite usable if you stay away from the bleeding edge features (mesa 3.1, dma/agp support).

grab a .deb, change its suffix to .tar.gz (or .tgz as you like), and untar/gunzip it.

This isn't precisely correct. You have to unar it first to get the tar.gz files. Coincidentally, there are detailed instructions for this in the accellerated glx project faq.

I've also heard that someone got documentation for the mpeg2 daughterboard matrox sells for the g100/200/400 graphics cards. They were going to write a driver for it, but I haven't heard anything since. I think there's supposed to be a website at livid.on.openprojects.net sometime soon, but there's nothing there as of this posting.

See also mpeg.openprojects.net for a what progress there's been on an open software decoder. Unfortunately, the MPEG2/DVD standard is pretty well tied up with patents (worse than mp3).

Finally, the original Berkeley group demonstration code is still available.

I've also heard that someone got documentation for the mpeg2 daughterboard matrox sells for the g100/200/400 graphics cards. They were going to write a driver for it, but I haven't heard anything since. I think there's supposed to be a website at livid.on.openprojects.net sometime soon, but there's nothing there as of this posting.

See also mpeg.openprojects.net for a what progress there's been on an open software decoder. Unfortunately, the MPEG2/DVD standard is pretty well tied up with patents (worse than mp3).

Finally, the original Berkeley group demonstration code is still available.

I guess everyone missed the opening of the G200 3d specs a while back -- in any case, there are GLX drivers for the G200 under Linux. Now. Go to http://www.on.openprojects.net/glx and grab a binary. Watch the gears screensaver go *real* fast, or heck -- leave it running in the background on your desktop. :) In any case, you can certainly try out Q3test with your G200. (In fact, under Linux a G200 is faster than a TNT(2) right now because of driver maturity. Go figure.)

So who's message is this this? Is it just some guy who worked at nvidia as a linux advocate, or just they guy who always answers the mail.

The fact that I thought it was going to be a binary *.so file is becuase of some other message there, I forget which. I think it was a reply from the guy who made that message.

(By "guy", i mean who the other guy is qouting. Get it:)

> has Matrox released the programming specs to the G400(Max)

This quote from a Matrox employee(?) recently appeared on the G200 developer's list:

> we plan to release G400 specs, same as we did for G200
> WARP specs are far to proprietary and cannot be given out at this point

The quoted document is here. The top-level link to the mailing list is here. The developers' page is here, and updated G400 info should show up there sometime after it becomes available (though the brief mention at the bottom has not yet been updated with the information quoted above).

BTW, talk among G200 developers on that list seems to indicate that they are within a leap of achieving the same acceleration that the Matrox-furnished drivers for Windows does, so it looks like another vindication for the OS development model, and a bright future for use of G200/G400 under Linux.

The WARP spec mentioned in the quote concerns a feature of the G200 that is not currently the driver's bottleneck, but will eventually limit the amount of acceleration achievable under Linux. However, there seems to be some "no promises" negotiation going on re the possibility of getting Matrox-furnished microcode to load onto the card for WARP support unless/until that spec can be released.

> has Matrox released the programming specs to the G400(Max)

This quote from a Matrox employee(?) recently appeared on the G200 developer's list:

> we plan to release G400 specs, same as we did for G200
> WARP specs are far to proprietary and cannot be given out at this point

The quoted document is here. The top-level link to the mailing list is here. The developers' page is here, and updated G400 info should show up there sometime after it becomes available (though the brief mention at the bottom has not yet been updated with the information quoted above).

BTW, talk among G200 developers on that list seems to indicate that they are within a leap of achieving the same acceleration that the Matrox-furnished drivers for Windows does, so it looks like another vindication for the OS development model, and a bright future for use of G200/G400 under Linux.

The WARP spec mentioned in the quote concerns a feature of the G200 that is not currently the driver's bottleneck, but will eventually limit the amount of acceleration achievable under Linux. However, there seems to be some "no promises" negotiation going on re the possibility of getting Matrox-furnished microcode to load onto the card for WARP support unless/until that spec can be released.

> has Matrox released the programming specs to the G400(Max)

This quote from a Matrox employee(?) recently appeared on the G200 developer's list:

> we plan to release G400 specs, same as we did for G200
> WARP specs are far to proprietary and cannot be given out at this point

The quoted document is here. The top-level link to the mailing list is here. The developers' page is here, and updated G400 info should show up there sometime after it becomes available (though the brief mention at the bottom has not yet been updated with the information quoted above).

BTW, talk among G200 developers on that list seems to indicate that they are within a leap of achieving the same acceleration that the Matrox-furnished drivers for Windows does, so it looks like another vindication for the OS development model, and a bright future for use of G200/G400 under Linux.

The WARP spec mentioned in the quote concerns a feature of the G200 that is not currently the driver's bottleneck, but will eventually limit the amount of acceleration achievable under Linux. However, there seems to be some "no promises" negotiation going on re the possibility of getting Matrox-furnished microcode to load onto the card for WARP support unless/until that spec can be released.

Yup, that is the G200 project I started that he is pimping. ;)

http://www.on.openprojects.net/glx

Url fix http://lists.openprojects.n et/mailman/listinfo/g200-dev
--

Look at lists.openprojects.net/mail man/listinfo/g200-dev
--

here it is for the 3rd time

http://lists.openprojects.n et/mailman/listinfo/g200-dev/A?

We have a fully functional GLX driver for the MGA-G200, it won't be complete until Precision Insight releases their Direct Rendering infrastructure some time in June. Right now mos windowed GL apps run *MUCH* faster, quake2 even runs but has poor performance that will be fixed with PI's driver architecture.

http://lists.openprojects.n et/mailman/listinfo/g200-dev

Binary-only drivers are not a solution, please do not support hardware that doesn't have free drivers. (Speech, not beer)

I agree totally, The TNT support will be binary-only, which means Redhat probably won't even distribute it, if they stick to the GPL that is. It will be interesting to see what they do. Not that I actually care about redhat... binary-only drivers are not good, if anything they are bad because they decrease the incentive to create a free driver.

However Matrox has done the right thing and released specs, we have made significant progress on the glx driver for the G200. See the following url:

http://lists.openprojects.n et/mailman/listinfo/g200-dev