From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JQL0d-0005Yp-Pw for garchives@archives.gentoo.org; Sat, 16 Feb 2008 11:15:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 59B3EE04E6; Sat, 16 Feb 2008 11:15:06 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 0078AE059C for ; Sat, 16 Feb 2008 11:15:06 +0000 (UTC) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JQL0Y-0007lp-3B for gentoo-amd64@lists.gentoo.org; Sat, 16 Feb 2008 11:15:02 +0000 Received: from ip68-231-12-179.ph.ph.cox.net ([68.231.12.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Feb 2008 11:15:02 +0000 Received: from 1i5t5.duncan by ip68-231-12-179.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Feb 2008 11:15:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: BT8x8 Date: Sat, 16 Feb 2008 11:11:58 +0000 (UTC) Message-ID: References: <47B66180.3000001@xaerolimit.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-179.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news Cc: gentoo-user@gentoo.org Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 15b4a93d-553e-4b78-bf68-f8e7c93933c4 X-Archives-Hash: fd48d53779f22cf756c59a6bab5de3f1 Chris Brennan posted 47B66180.3000001@xaerolimit.net, excerpted below, on Fri, 15 Feb 2008 23:07:28 -0500: > xawtv gives me a window and when I right click, I can choose what forma= t > and region and all that jazz, but I get no picture. >=20 > tvtime produces the following error: [reformatted] > *** tvtime requires hardware YUY2 overlay support from your > video card driver. [...] If unsure, please check with your > distribution to see if your *** X driver supports > hardware overlay surfaces. I don't touch proprietaryware so talk to someone else about that or try=20 the newest free drivers, which are supposed to support the R3xx series=20 chips including 3D. However, I can say this based on video behavior in general (and it worked= =20 the same on MSWormOS 98, with Nvidia hardware when I first switched to=20 Linux, and now with the Radeon R200 series stuff I'm running now as it=20 was the newest with freedomare 3D support for awhile, so this would=20 appear to be platform independent)... =20 When the overlay is working properly, particularly when there's nothing=20 playing, it should be quite apparent it's not a standard window. The=20 overlay will normally be blue-screen (tho I've rarely seen pink or orange= =20 or red, but always solid color), and doesn't obey normal window rules (no= =20 transparency, often no resizing, etc), as it's an "overlay". Overlays are definitely a feature of the hardware. Most video cards will= =20 have it, but some won't have the functionality exposed in the drivers. =20 If you don't have it, anything that must use it, no other choice, will be= =20 broken on your system. Fortunately, while it tends to be the lowest CPU most efficient method of= =20 playing video, most software video players and the like have other=20 choices as well. The overlay option is Xv, but most software can use one= =20 or more of standard surface mapping, OpenGL, xshm (generally more=20 efficient than standard surface mapping, less than Xv), or SDL video=20 rendering. (Of course SDL can in turn use OpenGL and a couple others.) Unfortunately, a lot (perhaps most?) TV capture hardware must use the=20 overlay, no other choice for it. That's reasonable as it's definitely=20 most efficient and least complicated for the hardware to access, but if=20 your video hardware or drivers don't support it, your SOL. So what I'd suggest is confirming that your video hardware and drivers=20 support it, then trying with something like kaffeine or kmplayer (the=20 video players I use). If you can get the overlay working there, then you= =20 at least know it's working before you try to get the TV capture hardware=20 going. As for your video drivers, as I said, the R3xx chip family is supposed to= =20 be supported with the newest open drivers, but I don't believe the 3D at=20 least is fully stable, yet. Hmm... just checked, they've updated, it now= =20 says "quite stable", but that's still not just "stable". This is with=20 pre-release xf86-video-ati (Gentoo package name) 6.7.19x (upstream=20 version) with Mesa 7.0.x. Gentoo's packages, mesa-7.0.2 is ~arch (and I have it merged here), xf86- video-ati-6.7.197 is ~arch but hard-masked: # Joshua Baergen (27 Mar 2007) # Release candidate ATI driver So you can try unmasking it and see how it goes if you want. As I said,=20 upstream calls it "quite stable" now, so it should work, tho there'll be=20 further changes as it continues to develop and fully stabilize. Some Radeon links from the x.org and dri.freedesktop.org wikis. The=20 first links the second but the link tends to get lost on the page, so I=20 put it here, too. The second is a portal page, with a bunch of links to=20 other resources, some of which look quite encouraging. http://www.x.org/wiki/radeon?highlight=3D%28radeon%29 http://dri.freedesktop.org/wiki/R300_Portal I'm /guessing/ that with the free drivers, you'll have overlay support=20 without much problem. If not, at least with them you'll be able to get=20 community support, something that's not so easy to get (or give) when the= =20 driver's a not so well supported black-box. Of course, you can check the= =20 documentation and/or ask and see. (As I said, I don't do proprietary, but= =20 if I were to do so, I'd certainly do NVidia, as at least they have decent= =20 Linux support even if it is proprietary. ATI Linux support of their=20 closed drivers has always been patchy at best, and of course the=20 community can't support them as they are closed. At least ATI's working=20 with the community on open drivers now as you're probably aware, but it's= =20 going to be a good year before stable drivers come out of that project.) --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman --=20 gentoo-amd64@lists.gentoo.org mailing list