If that pisses you off, get this: the new wireless connectivity standard for DVD players and TVs is limited to a range of a few feet due to MPAA pressure so that your neighbors won't be able to pick up what movie you're watching:
Originally Posted by bitnick
Well broadcasting a vga signal is always a security flaw when the display could show "interesting" infos. But lets compare that to HDCP. Just for the sake of hardware vendors you have to use a vga card and monitor/tv with HDCP. You absolutely gain nothing over pure DVI. And the only thing you could avoid is that you could not record the signal with a hd capable recorder. As the protection of hd dvd/blueray is already broken and could be even removed on the fly with a commericial tool a standard DVI connector would be enough. So what would you buy...?
The problem is depressingly simple. UVD handles #1 and #2 in the same block, and a lot of the setup operations are common between the functions. We haven't found a way to open up the info you need for #2 without also opening up #1.
Originally Posted by bitnick
Implementing #3 in the open source driver won't be a problem once the 3d framework is up and running, since we use shaders for #3 in the R5xx and higher chips. We are also planning to enable use of the parts of #2 which have not yet been moved into UVD.
Last edited by bridgman; 01-07-2008 at 07:08 PM.
Originally Posted by bridgman
well, if you could release information on how to setup the block for unencrypted streams you would not be in violation of anything while still allowing the open source driver the benefit of the UVD :-)
r300 - r400 opengl stuff
I myself am not too concerned about hardware accelerated video decoding right now. Someday it would be nice, but my AMD X2 4200 can handle most of the video out there right now. However I would love to see enough documentation to finish up the opengl 1.3 that is currently in the driver for smoothline, and a few other miscellaneous incomplete implementations that are being covered by the low impact fall back. I would also see enough documentation to finish up to at least opengl 2.0 or 2.1 so that the latest games will work with the opensource driver. After those opengl extensions were implemented then the driver could be optimized to be the fastest open driver however it is not easy reverse engineering. It takes a lot of patience (I've tried before) a little intuition to see how the device behaves with certain commands. Many more hours tweaking trying, and so having the information would allow the driver to be completed a lot quicker than it is currently being worked on. Also reverse engineering can require a considerable amount of resources since passing a bad command can let the smoke out. Most of the time these devices are engineered so that letting the smoke out is not likely to happen, but not every case can be tested and engineers are still human.
I'd really love smoothline and a better way to get the command buffer to play nicely so that Google Earth will play more nicely with the open driver. fglrx is fast, but unstable and has a few bugs that the open driver does not have. The open driver is stable except it isn't complete.