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 20 2010

SoundGraph iMON (and Antec Veris) LCD/VFD/IR devices

Category: Fedora,Linux,Linux Infrared Remote Control,MythTVjarod @ 11:59

Just a quick summary on the state of things with the SoundGraph iMON and Antec Veris LCD/VFD/IR devices, integrated into many Home Theater PC cases these days (as well as available as additions via 5.25″ bays in existing cases)…

So to start out, let it be known that there are three main classes of SoundGraph iMON devices out there these days:

  1. Really old stuff
  2. Device ID 0xffdc stuff
  3. Current stuff

The really old stuff isn’t particularly common. You can’t buy it new anywhere, so far as I know, and I’ve only ever run into a single person that actually *had* some of the really old stuff (by way of a bug report in Red Hat’s bugzilla). Its all usb-based, with the following device IDs (from the lirc_imon Linux kernel driver):

    /* TriGem iMON (IR only) -- TG_iMON.inf */
    { USB_DEVICE(0x0aa8, 0x8001) },
    /* SoundGraph iMON (IR only) -- sg_imon.inf */
    { USB_DEVICE(0x04e8, 0xff30) },
    /* SoundGraph iMON VFD (IR & VFD) -- iMON_VFD.inf */
    { USB_DEVICE(0x0aa8, 0xffda) },
    /* SoundGraph iMON SS (IR & VFD) -- iMON_SS.inf */
    { USB_DEVICE(0x15c2, 0xffda) },

The infrared receiver in these devices passes raw IR signals through to the driver, which the driver then passes to userspace (to the lirc daemon, lircd), which interprets them and maps them to keys, pretty much just like how most other IR receivers interoperate with lircd.

Now, the device ID 0xffdc (more on that in a sec) and the current stuff behave much differently. These devices do NOT pass raw IR signals, they have onboard IR signal decoders, which convert the received IR signals from raw IR to a unique hex code that represents a specific key. Historically, these devices have also been supported by the lirc_imon Linux kernel driver, and instead of passing raw IR signals to lircd, we simply send the hex code, which lircd would happily map to a key. However, the code paths traveled in lirc_imon by the really old stuff and the newer onboard decode devices diverge quite a bit, and with the onboard decode receivers, we can skip the lircd part entirely, and map the keys in the driver itself, since the raw IR signal has already been decoded.

Enter the imon Linux kernel input layer driver. I’ve split support for the onboard decode devices out of the lirc_imon driver and into a new driver, simply called ‘imon’. The decoded IR signal hex values are all mapped inside the kernel to standard input layer keys, so the driver works “out of the box”, without having to configure anything in userspace (such as lircd, which needs a config file mapping codes to keys, in addition to having to install and run the lircd program itself). I’ve submitted this driver for inclusion in the linux kernel, though my v2 submission (following v1 review fixes, cleanups and refactoring) seems to be stalled at the moment.

Back to the device ID 0xffdc stuff for a second… This snippet from the imon driver begins to explain the problem:

     * Several devices with this same device ID, all use iMON_PAD.inf
     * SoundGraph iMON PAD (IR & VFD)
     * SoundGraph iMON PAD (IR & LCD)
     * SoundGraph iMON Knob (IR only)
    { USB_DEVICE(0x15c2, 0xffdc) },

As you can see, the *exact* same device ID was used for several different devices, and to date, we don’t have any way in the Linux driver to differentiate between them. This is problematic, because we need to use different display write operations for the VFD and LCD, and of course, it makes no sense to set up a character display on a device without one. As a result, we currently offer a module parameter to specify attached display type, solely so that people can actually use their 0xffdc devices. Now, if I actually had one of these devices myself, with some spare time to snoop usb traffic under Windows, I might be able to figure out what the Windows drivers are looking at to determine which device type they’re talking to…

Fortunately, SoundGraph got a clue for their current lineup of stuff, and we’ve got things as they should be, with unique device IDs per device type, no overlapping. For these devices, we can auto-configure all driver parameters automatically, since we know based on device ID alone exactly what sort of device it is (well, except for the devices we don’t know details on yet, because either they’ve not yet been made/shipped, or nobody that has one cares about Linux…). The imon driver’s device ID table for the current stuff looks like so:

     * Newer devices, all driven by the latest iMON Windows driver, full
     * list of device IDs extracted via 'strings Setup/data1.hdr |grep 15c2'
     * Need user input to fill in details on unknown devices.
    /* SoundGraph iMON OEM Touch LCD (IR & 7" VGA LCD) */
    { USB_DEVICE(0x15c2, 0x0034) },
    /* SoundGraph iMON OEM Touch LCD (IR & 4.3" VGA LCD) */
    { USB_DEVICE(0x15c2, 0x0035) },
    /* SoundGraph iMON OEM VFD (IR & VFD) */
    { USB_DEVICE(0x15c2, 0x0036) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x0037) },
    /* SoundGraph iMON OEM LCD (IR & LCD) */
    { USB_DEVICE(0x15c2, 0x0038) },
    /* SoundGraph iMON UltraBay (IR & LCD) */
    { USB_DEVICE(0x15c2, 0x0039) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x003a) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x003b) },
    /* SoundGraph iMON OEM Inside (IR only) */
    { USB_DEVICE(0x15c2, 0x003c) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x003d) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x003e) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x003f) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x0040) },
    /* SoundGraph iMON MINI (IR only) */
    { USB_DEVICE(0x15c2, 0x0041) },
    /* Antec Veris Multimedia Station EZ External (IR only) */
    { USB_DEVICE(0x15c2, 0x0042) },
    /* Antec Veris Multimedia Station Basic Internal (IR only) */
    { USB_DEVICE(0x15c2, 0x0043) },
    /* Antec Veris Multimedia Station Elite (IR & VFD) */
    { USB_DEVICE(0x15c2, 0x0044) },
    /* Antec Veris Multimedia Station Premiere (IR & LCD) */
    { USB_DEVICE(0x15c2, 0x0045) },
    /* device specifics unknown */
    { USB_DEVICE(0x15c2, 0x0046) },

I’ve personally got the Antec Veris Multimedia Station Elite (VFD, device ID 0×0044) and Premiere (LCD, device ID 0×0045) devices. Both work out of the box with the latest Fedora development kernels, and their displays, when coupled with lcdproc 0.5.3 (or later). No lirc involved at all (though I could use it if I wanted to, talking to the imon driver via lircd’s userspace devinput driver). The only thing that really required any config work was lcdproc — LCDd needs to be told which of its drivers to use, which is ‘imon’ for the iMON VFD devices, and ‘imonlcd’ for the iMON LCD devices, with Protocol=0 for an 0xffdc LCD and Protocol=1 for the newer/saner LCD.

Jan 14 2010

The Broadcom Crystal HD and Linux story thus far…

Category: Broadcom Crystal HD,Fedora,Linux,Mac OS X,MythTV,Red Hatjarod @ 00:41

So at least six months ago now, I was first contacted by Scott Davilla of XBMC and AppleTV fame, whom I’ve had misc conversations with a number of times previously, (mostly about running MythTV on the AppleTV under Linux), about a very cool new toy he was playing with that would allow the AppleTV to play back 1080p h.264 material nice-n-smooth. Well, really not all that new a device, just new in the sense that there was actual traction on an open-source driver for it seeing the light of day. That device was the Broadcom Crystal HD decoder card, aka the BCM970012.

Now, the Crystal HD has been available as an OEM add-on for a number of systems with Windows drivers for a few years now, and prior to that, I think earlier incarnations existed in various set top boxes (which possibly were running some form of embedded Linux…). Dell has been shipping the decoder card for a while as the “Broadcom BD Accelerator card”. That would be BD and in “Blu-Ray Disc”. However, don’t get too excited about the prospect of a Linux Blu-Ray Disc playback solution just yet. More on that later… HP has been bundling the same card with their Mini 110 systems. Not too long ago, one of my favorite smaller online shops (juxtaposed to newegg or amazon), Logic Supply, which carries lots of hard-to-find-anywhere-else mini-itx and assorted embedded stuff, started selling the card as well.

Anyhow, Scott had put out some feelers about the Crystal HD, and managed to make contact with someone in Broadcom’s MediaPC division, who was in fact looking for community folks to help with Linux driver support. Amusingly, not long after I’d first talked to Scott about this, I talked to a guy I play pickup soccer with, who also happens to work for Broadcom, and he said he’d dig around and see if he could get me the name of someone to talk to about the Crystal HD as well. The name he turned up was the very same individual Scott had been talking to. Now, as you may or may not know, I happen to work for Red Hat, in its kernel group. I’m far from an elite kernel hacker myself, I’m just a trainee, if you ask me, but I work with some absolutely brilliant kernel people. This is attractive to someone like Broadcom looking for help with their kernel driver. :) Needless to say, the ball started rolling rather quickly at that point, and Broadcom’s Naren Sankar gave the thumbs up for Scott to pass along a copy of the full kernel driver and userspace library source for me to start poking at.

The code was… Well, typical of a lot of vendor code. For the most part, I cared first and foremost about the kernel driver. Lots of wrapper functions, rather than using kernel functions directly, Windows ifdeffery, and so on. But generally, pretty well laid out and thorough code, with reasonably good documentation in headers about what functions did, what register contents meant, etc. Okay, so on to compiling… Or not. My main development systems are pretty much all 64-bit Fedora, with fairly up-to-date kernels. Double-fail on that one. I can’t remember the exact details anymore, but it pretty much only worked on an older 32-bit kernel — Red Hat Enterprise Linux 5′s 2.6.18 kernel worked, as did Ubuntu 8.04′s kernel. If you’re gonna get the thing upstream, its kinda gotta work on the latest kernel, and be portable to 64-bit. So that was the focus of my late-night efforts for the next few weeks. Getting it to build on newer kernels wasn’t too much work. Making it build on 64-bit kernels was a lot more work. Then getting it to actually *work* on a modern 64-bit kernel was even more work. But now it does. :)

There was a bunch of additional code reformatting involved as well, so the driver looked more like Linux kernel code, then some assorted sanitization (libcrystalhd was originally called libldil — ldil being ‘linux driver interface library’ or something like that, and the crystalhd kernel module was originally called mpclink, iirc), new license headers, etc., a few more rewrites here and there to satisfy Broadcom legal, and finally, on December 29, 2009, a public release of the Linux kernel driver under the GPL, the Linux userspace library under the LGPL. From there, a bit more clean-up (being tracked in a git tree, of course), a submission of the driver to the Linux Kernel Mailing List by someone other than those of us who’d been working on it for the past 6 months (Manu Abraham graciously stepped aside when he found out we’d been working on it and planned to submit it), and then we finally got something off to lkml. On January 6, 2010, the driver was merged into the Linux kernel staging tree. Woo!

I’ve also patched the driver into the latest Fedora 12 and rawhide (F13-to-be) kernel trees, and submitted the userspace library as a new package for Fedora. Note that the firmware doesn’t yet have a license upon it that permits redistribution (redistributable, no modification, a la many other kernel driver firmware files), but Naren was working with Broadcom legal to make that happen. Note that the git tree I’m hosting builds on kernels going back at least as far as 2.6.18 (2.6.11, I think, but I’ve only tried back to 2.6.18 myself), and there’s source for a gstreamer plugin included in the tree. If you look at the Fedora package review bug, you’ll note that it doesn’t work so hot with current gstreamer, but it does work on older versions, and I’m hoping to get some help from one of Red Hat’s gstreamer gurus to fix it up to work with more current bits…

Speaking of firmware and getting back to that Blu-Ray Disc playback issue… The firmware for Linux does NOT include support for Blu-Ray Disc decoding. There are all sorts of “trusted path” requirements that would be… trick… to meet with an open-source driver. :( The driver doesn’t have code to support BD even if you did try loading firmware from a Windows driver that purported to support BD playback. Oh well.

Now, what we *can* support, is playback of MPEG2, h.264 and VC1 files. Without violating any (admittedly STUPID) codec patents here in the US or having to purchase a license. The decoding is all done in hardware. With almost no cpu usage. (Almost, because we do have to dma the encoded bitstream into the decoder, then dma out very large buffers full of raw video frames, and transplant that over to your gpu, but an AppleTV with its 1GHz proc can handle 1080p h.264 with this thing, so can a single-core Atom N270).

Scott has been hard at work adding Crystal HD support to XBMC and a port of the driver and library to Mac OS X, and has made excellent progress. Edward ‘gimli’ Hucek has been working on a xine plugin. Word has it a few ffmpeg developers have starting poking at support there too — which is the part I’m personally most interested in, as MythTV can inherit that work. (I actually started poking at MythTV code myself, seeing what needed to be added where to support the Crystal HD, but I’ve not had time to get up to speed on the code, nor will I likely anytime soon, and quite frankly, its probably better if the ffmpeg guys do the work, I’m really nowhere near as comfortable working outside the kernel… :) .

Oh, there’s also a very crude smoke-test app in examples/ in the crystalhd source tree. Its hard-coded to a specific video type in a specific file path, but its useful for sanity-checking if the decoder is working. It doesn’t display anything, it just takes in a clip, decodes frames, and spits back a bit of data about them, discarding the actual decoded video frame. More of just a developer usage thing, good for headless setups where ssh’d into a machine and the like. Ping me and/or Scott if you want to poke at it and need help making it behave, but most of the gory details can be seen in the post and comments over here in the Breaking Eggs And Making Omelettes blog, which if I understand correctly, belongs to one of the ffmpeg developers…

So yeah, that’s about where things are at right now… Stay tuned for updates, I’ll try to keep on top of them here…

Nov 20 2006

Long time, no blog…

Category: Baseball,Family,Linux,MythTV,Red Hatjarod @ 14:05

I must be the world’s laziest blogger… But hey, maybe I’ll make up for it today with some seriously hot blog-on-blog action (or something), covering ALL categories I’ve got created for this blog thingy…


So, me and my family are indeed over on the Atlantic side of the United States now, living in Tyngsboro, Massachusetts, just below the Massachusetts/New Hampshire border. Preston is 4 years old now and as crazy as ever, Kyla is almost 14 months old and walking/running all over the house now. We’re all looking forward to our first New England winter so we can do some serious sledding, skiiing, snow fort building, snow man building, snow ball fighting, etc. We never got more than a few days of snow every few years back in Seattle… Still need to get a snow blower or something, so we can dig our cars out once the whitewash hits…


I had surgery on my right shoulder two weeks ago to repair a torn labrum and various other bits I managed to damage somehow. The doctor basically reattached stuff in like four different places in there. In theory, I’ll be able to throw like I used to by the time men’s league ball starts up again in the spring. Our team is already one of the favorites for league champ next year with some new guys we picked up this offseason, and we’ll be just that more nasty if I make a full recovery (didn’t pitch at all last year, could hardly throw at all). Lots of rehab working coming up, still not supposed to do much of anything with the arm, but definitely looking forward to having my arm back.

Preston is trying to make up for my inability to play ball right now. He started playing t-ball at the local indoor sports complex a few weeks ago.

Red Hat/Fedora

Dude, I work for Red Hat. I love my job. Red Hat Enterprise Linux 5 is shaping up quite nicely. Of late, I’ve been busy beating on kdump, the new kernel crash dump mechanism we’re shipping in RHEL5, helping to whip it into shape on all supported architectures. Of course, a disproportionate amount of time has been spent making it play nice on non-x86/x86_64 architectures (i.e., ia64 and ppc64), but its been quite a bit of fun just the same.

On the home front, I’ve got this nice new fibre data pipe to my house, courtesy of Verizon FiOS, which just became available in my area. Got myself a business package with 5 static IP addresses so I can run whatever I want out of my house. That being the case, I moved my web and mail server back in-house after 6 months of having them hosted at a friend’s colo. The entire wilsonet.com domain runs on Fedora Core 6 boxes in my basement right now, with email services provided by the open-source edition of Zimbra. One of the projects on my todo list for this winter is to finally get around to setting up Asterisk, complete with tie-ins to Zimbra…

In some of the spare time I don’t really have, I’ve also been working on getting some amusing new packages into Fedora Extras. People love eye-candy, therefore, they love beryl, which is almost entirely into Fedora Extras now… :)


On the MythTV front, I managed to get a Fedora Core 6-based version of Fedora Myth(TV)ology out within the first month of FC6 landing, a vast improvement from the roll-out time on the FC5 version… All my Linux boxes at home are now running FC6 (though RHEL5 is going to make an appearance shortly too). Whether or not Fedora Myth(TV)ology morphs into something RHEL5-based remains to be seen… (Maybe a custom rebuild, a la CentOS, but called Myth Enterprise Linux, with a release codename of “Blanc” or “Gibson” or “Torme”)…

Oh yeah! I keep forgetting that I really need to plug the book on MythTV I helped write. A few months back, Hacking MythTV hit the book shelves. I actually just got a copy myself a few days ago. Nice looking book, full of MythTV goodness. Go buy a copy of Hacking MythTV!