Tony Houghton this.is.a.spam.trap@realh.co.uk Please see below to avoid spam trap 2004 Tony Houghton 18 November 2004 1.43 17 January 2007 Replaced link to unichrome project with openchrome. 1.42 9 January 2007 Corrected missing < in Voodoo patch recipe. 1.41 23 July 2006 Fixed link to subdomain. Added link to Martijn Uffing's bt869 patches. 1.40 23 July 2006 New location. Interlaced frame syncing in MythTV. Updated comment about getting MPlayer to compile with XvMC and nvidia-glx. New info about deinterlacing filters and MythTV glsync. 1.31 24 February 2006 Note about relocation to reduce bandwidth. Antispam paragraph more prominent. 1.30 11 February 2006 Updates for Matrox RGB out and DirectFB kernel patch and options. 1.21 31 October 2005 bt869 patch for kernel 2.6.14. 1.20 27 July 2005 Added more useful information about NVidia cards and tweaked Matrox section. 1.15 27 July 2005 Added new bt869 (Voodoo 3) patch for kernel 2.6.12, courtesy of Henrik Persson, and improved various remarks about Voodoo 3, interlacing and DirectFB. 1.14 4 February 2005 Separate modprobe commands for bt869 and i2c-voodoo3 1.13 4 February 2005 Corrected and updated directions for applying bt869 patches 1.12 4 February 2005 Missing GATOS chip IDs 1.11 3 February 2005 Need to build xfree86 for GATOS 1.10 3 February 2005 Results of testing with G200 1.9 24 January 2005 Unichrome driver for EPIA systems 1.8 20 January 2005 X.org doesn't support TV-out GATOS-style; update on ATI RGB (thanks to Jeremy Wilkins) 1.7 12 January 2005 X.org possible alternative to GATOS; DXR3 sound quality; maybe not all Matroxes support composite sync; new Matrox TV-out section; updated bt869 patch; misc small amendments 1.6 18 November 2004 DXR3 section and other minor changes 1.5 1 November 2004 More info about Matrox and interlacing 1.4 1 November 2004 BT869 support not in kernel 2.6.9 after all 1.3 24 October 2004 BT869 support in kernel 2.6.9 1.2 6 October 2004 MPlayer deinterlacing with -vsync -vo sdl 1.1 5 October 2004 Added paragraph about GATOS not supporting recent chips. Gave GATOS sections more meaningful titles 1.0 30 September 2004 First draft This article is a guide to getting a good TV picture (PAL or NTSC as opposed to HDTV) from a PC running Linux without an expensive external converter. The emphasis is on using the PC as some sort of video player, although some of the options are probably well-suited to playing games. Trying to do any sort of "work" using a TV screen instead of a monitor is not recommended. Some familiarity with terms such as VGA, RGB and S-Video is assumed as well as the ability to configure XFree86, compile the kernel and other software, and set boot-time module configurations. I can not guarantee the exact location of this document due to vagaries of whatever domain hosting package I'm using at any given time, but you should always be able to find it by going to http://www.realh.co.uk and following the link. I will also try to make it available directly at either http://www.realh.co.uk/tvhowto or http://tvhowto.realh.co.uk/. The email address above is fake to foil spammers. Please replace thisisaspamtrap with h and accept my apologies for the inconvenience. Most video cards should be programmable with suitable modelines for TV compatibility. However, not all have a composite sync option, so they need an external circuit to combine the horizontal and vertical sync signals. People have reported success with this technique using NVidia cards. A suitable circuit is detailed at http://www.hut.fi/Misc/Electronics/circuits/vga2tv/cindex.html. The article has several XFree86 modelines with comments for various video cards. There is an alternative description of the same circuit at http://tacashi.tripod.com/elctrncs/vga2tv/vga2tv.htm. http://www.nexusuk.org/projects/vga2scart/circuit details a simpler circuit with links to an RGB to S-Video converter. http://www.linuxnetmag.com/en/issue7/m7tvout1.html has another very simple circuit diagram and also a large table of modelines. http://www.epanorama.net/circuits/vga2tv/vga2palntsc.html details a more complicated cicrcuit to convert from VGA to S-Video and composite. Some cards have an option to generate composite sync signals with no extra circuitry. Certain Matrox cards and most cards based on ATI chips are thought to be capable of this. I've had success with a Radeon 9200SE, but failure with a Radeon 7000 and a Matrox G200 because their clocks wouldn't run at such a low frequency. Some Matrox cards can output TV-compatible signals on their second head, but only with specialised drivers instead of the mga X driver. See the Matrox TV out section, which includes a paragraph about RGB. http://ryoandr.free.fr has a simple wiring guide for ATI cards. There is similar information at http://www.idiots.org.uk/vga_rgb_scart/, but it claims to be no longer under development and superseded by the French site. For the Radeon cards the composite sync signal is present on the VGA connector's horizontal sync pin. I do not know whether the signal is also present on the vertical sync pin or whether Matrox cards are the same, but I should think they are, and it can easily be corrected by swapping the wire from pin 13 to 14 if not. Pin 9 on a VGA connector is officially unused, but on some cards it provides 5V, which should be suitable for the control signals described in the above article, although the 16:9 selection did not appear to work for me with my Radeon, so maybe the voltage dropped too far below 5V. This pin also carried 5V on my Matrox G200, but that was not capable of low enough frequencies for a TV. You may also like to know that pins 2, 6 and 4 on a SCART lead are audio right and left in, and audio ground respectively, so you can wire these up to a jack plug for your sound card too. All the above solutions require specific modes to generate frequencies correct for PAL. XFree86 modelines are sprinkled throughout the articles referenced. Unfortunately, finding one that works tends to depend on what sort of card you're using. I tried several with my Radeon 9200SE unsuccessfully until I generated one by looking at the screenshot of Powerstrip, a Windows utility, at www.idiots.org.uk and converting the numbers to an X modeline, using the conversion guide at http://www.knowplace.org/timings.html: Modeline "720x540PAL" 15.101 720 770 842 968 540 565 570 624 Composite Interlace A Radeon 9200 user reports that the 720x576 modeline at http://ryoandr.free.fr works, but was slightly off-centre, so he modified it to: ModeLine "720x576PAL" 15.125 720 770 842 968 576 579 607 625 Composite Interlace 720x576 is preferable to 720x540, being a match for PAL DVD resolution. The format of a modeline is described in the man page for XF86Config, and explained in the XFree86 Video Timings HOWTO. If you just want a quick hint, the second and sixth numbers in the line are the horizontal and vertical resolution respectively. TVs use unusually low frequencies compared to monitors, so you will need to change the HorizSync and VertRefresh parameters. Try these values: HorizSync 15-20 VertRefresh 50-60 Additionally, ATI cards often do not admit they can display such low frequencies when interrogated by the driver, so they need this option in the Device section to override it - the value in MHz corresponds to the 15.101 in the modeline above: Option "ForceMinDotClock" "15MHz" Many TV programs are interlaced ie each frame is split into two fields of alternate lines and displayed sequentially. This historically gave smoother pictures, but leads to problems when trying to display it. The interlacing looks fairly unpleasant on the desktop, and few video card and software combinations are able to sync fields correctly when playing back interlaced video streams. This leads to a shearing effect on a computer monitor, and juddery motion on a TV. Fortunately xine has a deinterlace option (-D or --deinterlace on the command line) which corrects this problem, but it does increase CPU usage and can cause motion blurring. You may need as much as 2GHz/XP2000+ of CPU performance to play DVB properly with deinterlacing, although the new Greedy deinterlacer is said to have considerably more modest requirements. I believe the Greedy filter appeared first in tvtime, a player designed for playing video from analogue capture cards, but unfortunately not optimised for displaying on a TV screen. MPlayer also has deinterlace filters. Alternatively, using a Matrox card with DirectFB allows the programme's interlacing to be synchronised with the TV out, providing a "perfect" solution. VLC is another popular video player, optimised for networked video streams. I have not tried it, but it claims to include a deinterlacing filter. MythTV is not really a video player, but a PVR with integrated video player. I mention it here because it's said to be able to use vsync interrupts provided by OpenGL or DRI to synchronise interlaced fields between a video and TV in a similar manner to MPlayer's dfbmga driver with Matrox cards. This requires the framebuffer to be running at the same speed as the video (50Hz or 60Hz) so would usually be used in conjunction with X through a VGA to RGB SCART adaptor as described above, or could potentially be used with a Voodoo 3. TV-out is a very common feature on graphics cards now. Most commonly they have an S-Video mini-DIN socket, which can also be used as composite with a simple hardware adapter, usually provided, and a configuration option. The advantage of S-Video over RGB is that ready-made leads are far easier to find and usually included. Some cards have a phono composite video socket instead, which is much the same as far as drivers and software are concerned. I recommend using S-Video if your TV supports it, because the quality is visibly superior to composite. There are two disadvantages of using this feature instead of RGB. The first is that most of the cards on the market now have rather poor quality TV-out. The second is that TV-out is an area that is neglected by the XFree86 developers, mostly leaving it up to third parties to provide extra drivers etc. Despite having earned a better reputation for picture quality on monitors than rivals NVidia in the past, ATI cards now seem to have the worst quality S-Video output. They work by scaling standard 800x600 or 640x480 resolutions to fit a PAL screen, which they do quite well; it's just a pity the overall quality is rather poor, with dull colours and some noise. You may find a genuine ATI or a good brand such as Hercules better than a cheap clone, and a short lead helps prevent any further degradation of the weak signal. For Radeon 8500 and newer cards, ATI's proprietary drivers may be slightly easier to set up than GATOS, especially if you also want to play 3D games, but GATOS is the only option for older cards.To configure the proprietary driver, use the provided fglrxconfig utility and answer the questions appropriately. Appropriate resolutions are 800x600 (recommended) and 640x480. GATOS is lagging behind XFree86 in its support for the latest chipsets:- at the time of writing it does not support 9200, 9600, 9800 or x800 series Radeons. However, I found that my 9200SE worked when I patched in the necessary chip ID etc from the driver source in the main XFree86 tree. However, I also had to comment out all references to R200_Qh through to R200Ql (note case) in the GATOS source because these chip IDs seemed to be missing. GATOS is lagging behind XFree86 in its support for the latest chipsets:- at the time of writing it does not support 9200, 9600, 9800 or x800 series Radeons. However, I found that my 9200SE worked when I patched in the necessary chip ID etc from the driver source in the main XFree86 tree. GATOS is a project to provide extra drivers for XFree86 to make use of the multimedia functionality of ATI cards. Getting it installed, especially for TV-out, looks a little daunting, but is simple enough given a recipe. The first thing you will need is the source code for the version of XFree86 you are currently using, eg download and install the SRPM for RPM-based distributions, or use apt-get source in the case of Debian. You will need to at least partially build it to generate the Makefiles etc needed by GATOS. TV-out is only available in one of GATOS' CVS branches, so make sure you also have CVS installed and run these commands: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gatos login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gatos co -r tv_output ati.2 Just press Return when the first command asks for a password. To build it when it's finished downloading run: xmkmf /path/to/your/xfree86/tree make make install where /path/to/your/xfree86/tree is the path to the top-level directory of the XFree86 source (directory name xc). make install must be run as root. To configure GATOS' TV-out in XF86Config or XF86Config-4, use the ati driver in the Device section as usual, but add this line: Option "TVOutput" "PAL" Other valid settings in place of PAL are NTSC, NTSC-J, PAL-CN, PAL-M, PAL-N or PAL-60. Use a resolution of 800x600 (recommended) and/or 640x480 in the Screen section. X.org is the successor to XFree86 for some distributions. Some of the GATOS code has been folded in, but not the TV out support. Apparently the developers are considering adding support, but maybe based on BeOS code rather than GATOS. In the meantime, I don't know whether GATOS can be installed with X.org. NVidia's proprietary driver (see http://www.nvidia.com/object/linux.html) supports TV out with X at 800x600 and 640x480 resolutions and is easy to configure, thanks in part to the good documentation (README) it is supplied with. It has some useful features such as support for displaying different pictures on a TV and monitor simultaneously, and being able to configure the size of the picture. Subjectively, with the cheap examples of each card I have tried, I felt that the quality of NVidia's scaler was worse than ATI's, but the NVidia had better brightness and colour balance. The latter bears out what I once read in a Usenet post by someone who had measured the signal strength of some cards and found NVidia to be stronger than ATI. I will not cover the details of setting it up, because that's covered very well in NVidia's README, but I will offer some tips and observations. I found that using X with TV out disabled the console (this could be because I was using a framebuffer console instead of plain VGA), so if using the card connected to a monitor and TV simultaneously (a good idea if not networked to another PC because text is barely readable on the TV) the best way to configure it is to combine the instructions for setting up the TV with those for setting up multiple X screens on one card. Currently these are appendixes J and R respectively. If the TV is set up as the secondary display (Screen 1), you can make a video player use it by setting DISPLAY=:0.1. TwinView (Appendix I) might be a viable alternative, but it may be more tricky to ensure a video player uses the TV in full-screen mode unless it's the primary device. When using MPlayer in full-screen mode I found that it reset the TVOverScan option if I used the SDL driver, but it was OK with Xv. Playing an interlaced video looked OK in terms of shearing, but this could have been partially obscured by the general blurriness, and the playback was not very smooth, as if the frame rate had been adjusted rather crudely. XvMC may help here, but at the time of trying I could not get MPlayer to compile with that enabled; I also had to disable MPlayer's OpenGL support. Newer versions of MPlayer seem to be free of those problems, but I have not had an NVidia card connected to a TV since. Certain Matrox cards are capable of S-Video/composite TV-out. They use a framebuffer of PAL or NTSC resolution with interlacing to avoid scaling, and allow field synchronisation of interlaced video with the output, so quality is very high without the need for a particularly powerful CPU. The disadvantages are overscan (picture too large so that the edges can't be seen) and that to make good use of it requires DirectFB instead of X, which can make setting up the software more difficult. MPlayer supports it very well; VDR's softdevice plugin works well with it too, albeit with some A/V sync issues, and Freevo can make use of it provided the SDL library has been compiled with the DirectFB driver. The Parhelia and newer cards are probably best avoided for Linux, due to Matrox not releasing programmers' information for them. I am not sure about the G200 and G400, but it appears that the G400's TV-out is compatible with Linux and at http://www.gossamer-threads.com/lists/mythtv/dev/2993?do=post_view_threaded there is a discussion about how to get a similar facility with a G200. The best bet though is with a G450 or G550. They can be bought cheaply from eBay etc and their second head connected to a TV via an adaptor. You can make your own adaptor using the schematic at http://forum.matrox.com/mga/viewtopic.php?t=4385 or order a ready-made one from Matrox's online shop. The price of the item itself is reasonable, it's good quality, and although the delivery cost is high, I found them to be prompt, at least in the UK, and I think you would have to be fairly frugal to be willing to take on such a fiddly soldering job. It's also difficult to buy lengths of "raw" double-screened cable suitable for S-Video, so if you must make one yourself it's probably more practical to sacrifice a ready-made S-Video lead. There is also a schematic for making an RGB SCART lead for a G450 at http://forum.matrox.com/mga/viewtopic.php?t=4383. DirectFB users have reported success with this; my understanding is that it works on the second head in the same way as S-Video, but higher picture quality may be expected. The wiring is fairly similar to that for ATI cards, the composite sync connection being the biggest difference. I don't know whether it works on other models besides the G450. There are two main HOWTOs for setting up one of these cards with Linux. http://www.bglug.ca/matrox_tvout/g450_tvout_howto.html is mainly concerned with using a TV to display an X desktop, while http://www.sci.fi/~syrjala/directfb/matrox-tv-out-howto is for using DirectFB for viewing TV and video etc via the DirectFB library. The latter is a more practical use for TV-out, and Matrox cards have the advantages of supporting several acceleration functions and allowing interlaced TV programmes (see above) to be shown correctly (for example with MPlayer's fieldparity=top sub-option). DirectFB's source tree includes some kernel patches. Most of them are not applicable for 2.6 kernels, but you may find that the matroxfb-full-memory patch (the 2.6 version is currently only available in DirectFB CVS) helps. I find that DirectFBCreate fails intermittently, and that the patch reduces the frequency of the failures. I don't think any of the kernel patches in either HOWTO are applicable to recent 2.6 kernels, although the fusion patches for DirectFB are optional (use of fusion is discouraged for certain applications such as VDR). Pekka Tiittanen and Ville Syrjala's HOWTO is a little outdated: the latest release of DirectFB is now 0.9.24 and the major number for the fusion devices has changed from 253 to 252. There are some additional directfb options you may need if you're using the PC without a console and don't want to have to run DirectFB applications as root: no-graphics-vt no-vt-switching no-vt-switch and/or no-vt Additionally, MPlayer may need the noinput sub-option to -vo eg: -vo dfbmga:frameparity=top:noinput if you are not using the host machine's keyboard. See also the disable-module options in directfbrc. Some models of 3Dfx's Voodoo 3 series were equipped with TV-out using a Brooktree BT869 chip. The quality is very good at a native PAL resolution of 720x576, and presumably also at 720x480 NTSC, but there is some overscan (edges of picture missing); this is fairly common with most TV picture sources, so should not be a problem for watching TV and video files. It can also display 800x600 and 640x480, but loses a lot of quality in the scaling and introduces large borders. For the interlaced native PAL (and NTSC?) modes see the interlacing section. These cards are readily available on eBay for about £10, and are widely compatible with video software due to being able to display X on the TV output, so they are a good choice when putting together a HTPC, provided you have enough CPU power for software deinterlacing if necessary. Do check that your motherboard is compatible, because several different flavours of AGP have evolved over the years, and Voodoo 3s are quite old now. See http://www.ertyu.org/~steven_nikkel/agpcompatibility.html. The connector on mine indicates that it's a 1.5V card. The vast majority of motherboards should be OK with this. Most of the information in this section came from http://www.linuxnetmag.com/en/issue7/printm7tvout2.html and the documentation for lm_sensors' bt869 driver. In common with many cards the TV-out is activated automatically when the PC boots, but loses sync when you change mode eg by starting X. Unlike most of the other cards, reenabling it is not done by the XFree86 driver, but via the card's I2C interface, and requires specialised modelines detailed in the bt869 driver documentation. It requires the Voodoo 3 and Brooktree BT869 I2C drivers. Download the latest versions of lm_sensors and i2c from http://secure.netroedge.com/~lm78/. Installation is basically a case of making sure the kernel's own I2C support is disabled, then running: make make install for the i2c and lm_sensors source trees in turn. Also make sure your kernel supports the /proc filesystem and that it's mounted in /etc/fstab. This is nearly always essential anyway, so you can probably take it for granted that it's already working. The bt869 driver is not supported in kernel 2.6, but you can add the driver as a patch. I originally found a suitable patch by Toby Reed at http://archives.andrew.net.au/lm-sensors/msg18457.html and have been sent updated versions since. Martijn Uffing has undertaken to keep the driver up to date for recent kernels (2.6.14 and later) and to host his patches at http://sarijopen.student.utwente.nl/caligula/kernel/patches/. He also provides versions with the flicker filter enabled. To apply one of these patches: cd /usr/src/linux/ patch -p1 < /path/to/downloaded/patch You can now skip to Configuring the kernel. For kernel 2.6.12 Henrik Persson sent me a patch which you can download from here. To apply this: cd /usr/src/linux/ zcat /path/to/downloaded/patch | patch -p1 You can now skip to Configuring the kernel. The original patch was for kernel 2.6.8.1 and also works up to kernel 2.6.9. If you have one of these kernel versions download kernel-2.6.8.1-bt869.patch.gz and apply it thus: cd /usr/src/linux/drivers/i2c zcat /path/to/downloaded/patch | patch -p0 If you have kernel 2.6.10, apply the 2.6.8/9 patch above, followed by bt869-2.6.9-to-2.6.10.patch.gz, also supplied by Toby Reed. cd into the chips subdirectory and apply it as above. Unfortunately I do not know which patches work, if any, with kernels 2.6.11 and 2.6.13. If you have one of these versions and can nout upgrade you will have to try the patches for the nearest version. If you find a patch only partially works and you need to undo the changes it made, use the same command as you used to apply it but add the -R option. Configure the kernel in your favourite manner, and go to the I2C section in Device Drivers. You will probably want to enable the drivers as modules rather than built into the kernel. Enable at least I2C support, I2C bit-banging interfaces (in I2C Algorithms), Voodoo 3 (in I2C Hardware Bus Support) and Brooktree BT869 (the one we added with the patch, in I2C Hardware Sensors Chip Support). You may also need to enable EXPERIMENTAL ie Code maturity level options => Prompt for development and/or incomplete code/drivers to access all of these, especially if you added the bt869 driver as a patch. Compile and install as usual. It may be worth your while to download lm_sensors even though it isn't necessary, so you can read the documentation for the bt869 module. Make sure both drivers are loaded with modprobe bt869 modprobe i2c-voodoo3 Some pseudo-files will be created under /proc or /sys depending on whether you have a 2.4 or 2.6 kernel respectively. The directory containing them is fairly easy to find in /proc: it is called /proc/sys/dev/sensors/bt869* where * will look something like -i2c-0-44 but varies slightly from system to system. In 2.6's /sys it's somewhat more obscure. I use this script fragment to find it: DEVDIR=/sys/devices/ # for 2.6 kernels, or DEVDIR=/proc/sys/dev/sensors/ # for 2.4 kernels DEVDIR="$(dirname $(find $DEVDIR -name svideo))" or, to work on either kernel version (until something newer than 2.6 comes along): if `uname -r | grep -q 2.6` ; then DEVDIR=/sys/devices/ else DEVDIR=/proc/sys/dev/sensors/ fi DEVDIR="$(dirname $(find $DEVDIR -name svideo))" The useful files are: res, depth, ntsc, svideo and colorbars. To select the resolution, echo it to the res file eg: echo 720 576 > $DEVDIR/res Similarly for colour depth: echo 24 > $DEVDIR/depth although some people seem to find it only works at the default of 16-bit. Make sure it matches your X configuration. Select PAL instead of NTSC by echoing 0 to ntsc (1 if you want to use NTSC after all). I presume 1 to svideo confirms you want the default of S-Video while 0 selects Composite. The above commands should be run when starting X, so I run them from .xinitrc or .xsession. However, you will need root access so I put them in a separate script and call it with sudo. They also tend not to work first time at each startup of X. One solution offered by the bt869 documentation is to turn colorbars on and off (echo 1 and 0 respectively) after applying the other settings, or simply read the colorbars file with cat. Or you can try applying the other settings again after a short delay eg, if they're in a script /usr/local/sbin/voodootv: sudo /usr/local/sbin/voodootv (sleep 2 && sudo /usr/local/sbin/voodootv) & The BT869 is compatible with these modes: ModeLine "640x480PAL" 29.50 640 675 678 944 480 530 535 625 ModeLine "720x576PAL" 27.50 720 744 800 880 576 581 583 625 ModeLine "800x600PAL" 36.00 800 818 820 960 600 653 655 750 ModeLine "640x480NTSC" 28.195793 640 656 658 784 480 520 525 600 ModeLine "720x480NTSC" 27.5 720 744 800 872 480 483 485 525 ModeLine "800x600NTSC" 38.769241 800 812 814 880 600 646 649 735 You will need to select a mode that matches the one passed to the i2c driver. I recommend using 720x576PAL or 720x480NTSC to avoid the somewhat ropey scaling. These mini-ITX boards deserve a mention. Their very small form factor and low power consumption makes them popular. The TV-out works automatically without any special intervention, provided you stick to a standard mode such as 800x600; however, I've heard a rumour that recent drivers may support PAL resolutions natively. The signal is reported to be a little weak, but quality is OK with a short cable. Some models also have an on-board MPEG decoder, which should make them good for playing digital TV and DVDs. Best support currently appears to be available with the openChrome drivers from http://openchrome.org. Creative's DXR3 and Sigma's REALmagic Hollywood Plus cards are very similar pieces of hardware. They were designed for viewing DVDs back when most PCs did not have enough processing power to decode the MPEG. They can either superimpose video on the desktop and output to a monitor with a VGA socket, using a passthrough cable (notorious for degrading quality) from the PC's main graphics card, or output the video to TV (S-Video or composite). It also has its own sound output (SPDIF and stereo jack) which is useful if, like me, you are rather short of PCI slots and your motherboard lacks onboard sound, or its onboard sound is too quiet when connected to a TV. However, I found the stereo output on my DXR3 a little weak compared to even my £5 CrystalMedia-based soundcard. The SPDIF is probably much better. The availability of fast, cheap CPUs etc has largely obsoleted these MPEG decoders, but they are very useful for HTPCs because of the high quality TV out and their ability to display interlaced material correctly (see the section on interlacing), and play MPEG (1 & 2) much more efficiently than a CPU. They can be bought second-hand, eg on eBay, for about £10, but they are not as common as old graphics cards such as Voodoo 3s. Although the hardware is really only capable of playing MPEG 1 or 2 material, some applications, most notably MPlayer, can display other formats by using a filter to convert to MPEG 1. Although there must be some conversion losses, the result on a TV is probably better than most graphics cards due to the respective quality of the TV output. You will need a reasonably fast processor. Most people say you need at least 1GHz; my 1.2GHz Celeron seems to cope well with reasonably high quality MPEG 4 without dropping frames and plenty of headroom in the CPU load. The downside of these cards is that they tend to lose synchronisation between sound and picture, at least with current Linux applications, but this can be worked around with MPlayer's A/V delay controls, and the developer of the DXR3 plugin for VDR is working on the problem too. The driver is available from http://dxr3.sourceforge.net. At present you need to use CVS if you want to use it with kernel 2.6: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/dxr3 login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/dxr3 co em8300 (Just press Enter when prompted for a password). The driver is called em8300 after the main chip on the card. There is a Howto on the website but it tends to get bogged down in detail rather than provide a straightforward guide. If there is a configure script in the version you downloaded, skip to the next paragraph. But if you downloaded from CVS, you need to create it by running bootstrap. You will need libtool, automake and autoconf for this. You can build the tools in the usual way: ./configure make make install but the modules have to be built separately. Go into the modules directory and run make and make install there. Also run make devices to create the device nodes in /dev. There are three modules altogether, em8300, adv717x and bt865. You need the em8300 module and one of the other two depending on your particular card. The Howto suggests that DXR3s use bt865 and Hollywood+'s use adv717x, which may require some options depending on revision. The Howto lists some module options and loader scripts, but I did not find this information particularly useful and simply added em8300 and bt865 to /etc/modules. Microcode is included in current versions of the em8300 module so you do not need to worry about it in normal use. If you want to reload it with em8300setup the file is available as modules/em8300.uc in the source tree. Applications such as MPlayer and VDR should not need this, but it still has its uses. Run em8300setup -h to see a list of options. One point to note is that for use on a 16:9 TV the -o and -w options seem to be the wrong way round. Therefore you may need to run em8300setup -o after starting playback. To enable DXR3/H+ support in MPlayer you need to install the library from the em8300 driver before compiling MPlayer, then it should be auto-detected. MPlayer has some very good HTML documentation, including details of how to use it with a DXR3 or Hollywood+, so there is no need to add much here. However, one point it does miss is what quality setting to use for the lavc filter (conversion to MPEG). A value of 0 uses the best quality possible; if you have problems with dropped frames try 10000 and keep reducing it until you find a suitable value. If there are still problems at 5000 you may unfortunately not have enough CPU power to do it justice.