Oct 11 2010

What’s new in IR?

Category: Fedora,Linux,Linux Infrared Remote Controljarod @ 20:39

A whole lot of activity has been going on in the upstream Linux kernel with respect to infrared remote control support lately. The release of kernel 2.6.36 is almost upon us, and that’ll bring the first kernel release with the lirc drivers included. A few have already been ported to the new ir-core in-kernel decoding infrastructure (imon, mceusb, ene and streamzap), with more in the works as time permits. Both Fedora 14 and Ubuntu 10.10 are shipping with backported lirc drivers and ir-core bits (albeit at the moment, the Fedora bits are much newer, but I’ve poked some Canonical folks to see about getting them updated too), as well as lirc 0.8.7-based userspace patched up to work with the in-kernel lirc bits. Fedora 14′s release is still another few weeks out, while Ubuntu 10.10 was just released a few days ago. Seeing a bit of fallout from the changes — mostly Ubuntu users updating and finding things don’t work exactly the way they did before. Stay tuned for an FAQ-ish document on the changes made and how to adapt, will try to get something together sooner than later…

So what else is coming? Well, included in those slightly-newer-ir-core patches in Fedora 14 is a new driver for the Consumer IR functionality in the Nuvoton w836x7hg LPC Super I/O chip, which is found in the ASRock ION 330HT systems. Nuvoton provided me with one of these systems and full documentation on the chip, as well as some sample code in the way of an lirc driver, all of which I’ve used to write a new ir-core driver, which goes by the moniker nuvoton-cir. Seems a few Intel DP55-series motherboards also have these Nuvoton chips on them, so I’m hoping to get ahold of one of those at some point (the ASRock only has RX, the Intel boards may also have TX wired up). The nuvoton-cir driver is currently pending being pulled into the v4l-dvb tree and then along to Linus’ tree for 2.6.37-rc1. Also in the Fedora 14 kernel and already in the v4l-dvb tree, awaiting pull to 2.6.37-rc1 is a fairly large overhaul of the imon driver, which greatly improves locking and key release semantics (mostly courtesy of David Härdeman, with bits and pieces from me mixed in). There’s also a significant amount of updates to core ir-core functionality and the ene_ir driver from Maxim Levitsky (some of which was studied for inspiration in how to write the nuvoton-cir driver). Finally, David also has a port of his winbond-cir driver from a misc input driver to an ir-core driver, which should be merged just after 2.6.37-rc1 (as it depends on some additional code restructuring that depends on some other code, etc…).

Completely unrelated to ir-core, I also picked up a TiVo Slide remote a little while back. Its a hybrid bluetooth/IR remote that comes with its own bluetooth dongle, which when properly paired, results in the remote sending bluetooth commands to the dongle that are delivered to the host system as pure HID usages. Unfortunately, for Linux users, and less unfortunately for me, since it was fun to get it working, it doesn’t yet work right out of the box, as the Linux HID layer didn’t yet fully support all the usages it reported. I’ve submitted a patch for this upstream to the linux-input mailing list, which will hopefully also make 2.6.37-rc1 (its also been backported into the Fedora 14 kernels).

On the userspace side of things, I’ve finally pushed a ton of lirc changes for what will eventually become lirc 0.9.0. Both the still-included kernel modules (many of which I’m thinking of neutering soon) and the in-kernel lirc drivers should work interchangeably with this lirc userspace, if I’ve done things correctly. I haven’t yet cut an lirc 0.9.0-pre1 tarball though, as I’ve been talking with Paul Bender (of minimyth fame) about merging his eventlircd code into the main lirc distribution, as I think its actually a better fit for many use cases where we’re ultimately trying to get linux input layer events translated into commands for a given application (ir-core remotes operating in their native mode send linux input layer events, as do HID devices like my TiVo Slide).


Jul 14 2010

LIRC finally landing upstream

Category: Fedora,Linux,Linux Infrared Remote Controljarod @ 15:41

So after several years of existing out-of-tree, we’re finally making some headway with landing lirc in the upstream Linux kernel. As of 2.6.36, the core lirc device interface (lirc_dev) driver will be merged. We also have a new in-kernel IR protocol decoding infrastructure, currently dubbed “ir-core” (possibly to be renamed to “rc-core”, reflecting a desire to generically support remote controls using signaling other than infrared), which allows for zero-configuration, works  just like a keyboard remote control support, right out of the box. IR decoders are “plugins” to this new infrastructure. I’ve also ported the old lirc_imon and lirc_mceusb drivers to this new infrastructure — the “imon” driver is in 2.6.35, the “mceusb” driver will show up in 2.6.36. So what good does this do without any lirc_foo device-specific drivers, you ask? Well, for one, all the current lirc_foo drivers will be able to be built out-of-tree against an in-kernel lirc_dev. I’ve also put together some entirely new code, in the form of an ir-core IR decoder plugin, which bridges between any in-kernel raw IR decoding driver and lirc_dev. This means that while out of the box, the mceusb driver and stock remote Just Work(tm) via the Linux input layer, you can *also* choose to pass the raw IR along to the lirc decoder plugin, which allows you to use lirc exactly as you would have with lirc_mceusb — decoding done in userspace via lircd. Calling the lirc plugin a decoder plugin is also a bit misleading. Its actually bi-directional codec bridge, meaning you can *also* transmit IR via the blasters on the mceusb devices using the mceusb driver with the lirc decoder plugin.

So what’s next? Well, I’ve got some work to do to make the lirc userspace happy with this merged in-kernel lirc_dev, as there were some assorted interface changes required to make lirc_dev suitable for upstream inclusion. After that, I plan to submit most of the current lirc_foo drivers into the Linux kernel staging tree, building against the in-kernel lirc_dev, but with a caveat that they’re all being put there with the intent that they be ported to the ir-core interfaces, or dropped entirely. I plan on working on as many of these as I can myself, but if they’re in staging, hey, maybe some more people jump in and help.

We’re going to release lirc 0.8.7 Real Soon Now(tm) as the last “legacy”-ish lirc release (hopefully), then we’ll be hard at work (actually, I’m already working on) lirc 0.9.0, which should fully support the in-kernel lirc bits.


Jul 14 2010

New crystalhd support has landed

Category: Broadcom Crystal HD,Fedora,Linuxjarod @ 15:40

Well, it took a bit longer than I thought it would (and I suck at regular updates here), but the Broadcom Crystal HD bcm970015 cards are now working quite well under Linux. I swapped out the older 12 hardware for some 15 hardware in my thinkpad t61, and the driver now happily loads, library handles firmware uploads as appropriate for this hardware, gstreamer plugin builds, installs and even *works* using totem on fedora 13 with at least one h.264 sample clip I’ve got.

Broadcom ended up doing the bulk of the work (big thanks to Naren and his team at Broadcom), and have brought the driver and library pretty much up to full parity with their Windows driver. There’s been a lot of churn, and quite a bit of the new code (at least on the driver side) needs significant work to clean it up and make it look more like Linux kernel code before it can be sent along for upstream Linux kernel inclusion, but the important part for now is that its working.


Apr 01 2010

New Crystal HD device support Coming Soon (I swear)

Category: Broadcom Crystal HDjarod @ 01:01

Hrm, been a while since I’ve posted anything… Anyway, we’re busy working on support for the bcm970015-based Crystal HD decoder card now. At the moment, the git tree is a bit, um, unstable… The driver is at least working again on a bcm970012 part with some basic test code (hellobcm) if I use an older libcrystalhd, while the current libcrystalhd segfaults on me. We’ll get to the bottom of that soon… Kernel driver side support for the 15 is also getting there, but not quite ready yet.


Feb 10 2010

Crystal HD price drop and coupon

Category: Broadcom Crystal HD,Linuxjarod @ 15:56

Logic Supply once again has stock of the Broadcom Crystal HD cards, now down to $55.00, and with a $10 off coupon code, XBMC10. Get ‘em while they’re hot! (At least, I think the coupon code is still good…). I’ve been too busy to poke at mine for a few days, but I’ve got several of the newer bcm970015 part in hand now that I need to start working on support for in the crystalhd driver…


Feb 10 2010

MythTV 0.23 and Arclight

Category: Fedora,Linux,MythTVjarod @ 15:34

Been meaning to post this for a few days now… I made the jump over to pre-0.23 MythTV svn builds at home about a week ago now, and along with it, picked up a copy of Robert McNamara’s excellent new Arclight theme, which from the link there, you can see is now in MythTV’s svn repo, despite Robert’s earlier plan to release the theme under a Creative Commons no modification license and a need to purchase a font (Frutiger) for use with it. Its been released by Robert as GPL, and reworked to use freely redistributable fonts, League Gothic and CartoGothic Std (both included in the MythTV svn repo, and will likely be installed for you as part of the mythtv-themes package(s) for the various Linux distros — it will be for Fedora, I’ve started building svn trunk packages for Fedora 13 (current rawhide). I haven’t seen a side-by-side comparison of screen shots with Frutiger vs. the Gothic stand-ins, but it looked damned good to me in both the earlier screenshots I’d seen with Frutiger, and as it exists now on my main MythTV frontend at home.


Jan 26 2010

Crystal HD vs. nVidia VDPAU decoding/playback

Category: Broadcom Crystal HD,Linuxjarod @ 13:49

I’ve been doing a fair amount of experimenting, mostly using xbmc’s svn trunk code, comparing the playback quality, cpu usage, codec support, etc. of both Broadcom Crystal HD-based decoding and nVidia VDPAU-based decoding of assorted video files I’ve got around the house. Now, open-source crystalhd support under Linux is quite new, as some of you may know. But the chip and driver have actually been around for quite some time, lurking in assorted set top boxes, if I understand correctly. The chip and driver, so far, seem pretty robust (not surprising, if they have indeed been in set top boxes for some time now), and definitely highly capable. nVidia’s graphics cards have been able to do video decoding for probably at least as long, but until a year ago or so, only the Windows drivers supported that functionality, so VDPAU is relatively new as well, but its usage is a bit more established than the crystalhd in the world of open-source. (Note, of course, that while there’s an open-source libvdpau, the only way to provide a working decoder backend for libvdpau is via binary-only drivers from nVidia or S3, the latter of which I know nothing about, so for the open-source purists, crystalhd is a win here).

The question many people have asked me (on mythtv irc and mailing lists, primarily), is ‘how does it compare to VDPAU?’. Well, it compares quite favorably. I’ve got a development box with an nVidia Quadro FX 1700 and a Broadcom Crystal HD card in it that I’ve been poking at the past few nights. For fully-compliant h.264 streams, there’s little or no difference in the quality of the decoders, with maybe a *slight* (and possibly only perceived and subjective) edge to the Crystal HD decoder. They’re both quite good. Like, you can’t tell this is a desktop computer playing back the video and not a commercial blu-ray player good. At the moment, less-than-100%-spec-compliant h.264 clips tend to give the Crystal HD fits, while they play fine using VDPAU. However, most of that is software-side, and can/will be remedied as development progresses.

As for mpeg2 (aka High-Definition TV in the US), the Crystal HD does support that as well, but most work has been focused on h.264 to date. The mpeg2 decoding via Crystal HD in xbmc isn’t quite there yet, but Scott has been working on it. A few days ago, 1080i mpeg2 content had a nasty green cast to it, along with alternating light and dark stripes. The green cast is gone now, but the stripes persist — it also looks like either fields are playing out of order or being drawn in not quite the right locations, visually manifesting as the picture oscillating up and down a pixel or two. Both 720p and 1080i lose sync after a bit as well, and then the player thrashes about trying to get them back in sync (or something). But they’re known issues, and progress is being made.

I have to add this data point though: while playing back some 1080p h.264 video decoded by the Crystal HD this past weekend, my wife said “wow, that looks so good! why does it look so good? I don’t remember it looking that good before!” (more or less). :)

So why should you choose one over the other? Depends on a few things… If you’re in the camp that is morally opposed to binary-only software, such as the nVidia graphics driver, the Crystal HD route is far less morally reprehensible. It *does* require use of a binary-only firmware image that must be loaded onto the card, but otherwise, the driver and interface library are 100% open-source (GPL driver, LGPL library). The driver is in the Linux kernel staging tree, and the library is making its way into Linux distributions. The Crystal HD isn’t dependent on any particular graphics chipset either. I’ve got an Intel X3100 graphics Lenovo ThinkPad T61 and an Intel GMA950 Mac Mini, neither of which I could replace the graphics chipset in. Both have mini PCIe slots though. And now both can play back 1080p h.264 using the Crystal HD, whereas before, notsomuch. Note however, that there are higher cpu and memory requirements for using the Crystal HD to decode video than for VDPAU. This is the down side of it not being tied to a particular graphics chipset. Because its a separate device, there is occasional format conversion (rgb to yuv, nv12 to yv12, etc., etc) and buffer copying (from Crystal HD to graphics card) that has to be done, rather than everything occurring strictly within the graphics chip. That said, even a lowly 1GHz AppleTV with 256MB of RAM can play back 1080p h.264 with a Crystal HD (its just pretty close to maxed out). Chances of having a PCI express-capable chipset with a CPU slower than that are minimal. Single-core Atom systems, particularly in netbooks, are one of the main targets for the Crystal HD.

Back to the hardware for a moment… To make room for the Crystal HD in my T61, I yanked the worthless-under-Linux Intel TurboMemory card. In the Mac Mini, I yanked the wifi card, since I have wired GbE to it. If you have a system with an available PCIe slot, its probably easier to simply drop an nVidia graphics card in — partially because the Crystal HD is only generally available in a mini PCIe card format right now, meaning you’d need an adapter to use one in a PCI express system w/o a mini PCIe socket (but these do exist). Remember the above-mentioned development system w/the Quadro FX 1700 in it? Its actually a tower with no mini PCIe socket — I have a PCIe x1 Crystal HD card courtesy of Broadcom, its just not available anywhere on the open market at this time. They’d like for it to be, as well as an expresscard variant (for laptops without an available internal mini PCIe socket to spare), but the mini PCIe is likely to be the one most in demand by far, so only time (and market conditions) will tell what options become available.


Jan 22 2010

Elgato Turbo.264 HD and Linux

Category: Linuxjarod @ 20:11

Some time ago, I picked up an Elgato Turbo.264 HD stick to play with. At the very least, its something I can use with my Mac computers under Mac OS X. In the long run, I thought it might be fun to poke at it under Linux and see if it couldn’t be made to work there. Today in #mythtv-users on freenode, Devin Heitmueller pointed me at an already-under-development libcrusher264 ffmpeg patch for it. Very cool. The HD variant I have isn’t yet supported, but its a great start. I’ll have to poke at that more some day. In the mean time, it works pretty damned well with my 17″ MacBook Pro under Mac OS X, and I’ve got way too many other things to work on with higher priority anyway…


Jan 22 2010

Crystal HD and xbmc

Category: Broadcom Crystal HD,Fedora,Linuxjarod @ 02:37

They work fantastically well together. Scott Davilla, who is the one that got the ball rolling on open-sourcing the crystalhd driver and library and brought me into the fold, has done an outstanding job with the xbmc development trunk code, adding support for offloading decoding to the crystalhd. I grabbed the Big Buck Bunny 1080p h.264 clip and threw it at a build of today’s xbmc on an x86_64 Fedora 12 install on my Lenovo ThinkPad T61 (sporting a Core 2 Duo processor at 2.2GHz and Intel X3100 graphics), and the system hardly broke a sweat, topping out at 39% cpu usage, with absolutely flawless decoding and perfectly smooth playback. Juxtapose this with mplayer operating on the same file, pegging one cpu core, with obvious dropped frames, stuttering, etc. Good stuff.


Jan 21 2010

Crystal HD xine plugin

Category: Broadcom Crystal HD,Fedora,Linuxjarod @ 12:04

Managed to hack together a xine-lib-1.2 hg development tip rpm for Fedora 12 last night. After getting that installed on my ThinkPad T61, the xine crystalhd decoder plugin built without a problem. Installed it, and let xine have at it with an h.264 clip from my Hauppauge HD PVR. Lo and behold, it works! Not exactly perfect just yet — there was a xine process spinning at 120% in top during playback and the video didn’t quite look smooth — but it did play back the video, decoded by the crystalhd. More poking later. Need to take a closer look at xbmc’s crystalhd support too.


Next Page »