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.

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

IR send/receive and the Hauppauge HD-PVR

Category: Fedora,Linux,Linux Infrared Remote Controljarod @ 14:43

The Hauppauge HD PVR has been a supported video capture device under Linux for quite some time now. The MythTV 0.22 release officially added support for it as a capture device under Linux. However, because the HD PVR records via an analog input, not via a tuner, you need a way to change channels on the device feeding it. The HD PVR has a built-in IR receiver and transmitter, sitting on an i2c bus on the device, not unlike a number of other Hauppauge devices. Well, with a wee bit of hacking on the hdpvr driver and the lirc_zilog driver, we *can* enable the IR part and use lirc with it.

Here’s a patch against the hdpvr v4l/dvb driver to enable the IR part:
* http://wilsonet.com/jarod/junk/hdpvr-ir/hdpvr-ir-enable.patch

Then you need lirc_zilog, which isn’t in the upstream lirc tree due to concerns over its use of a ‘firmware’ image for its IR transmit tables. I’m maintaining lirc_zilog in my lirc kernel driver git tree though:

* http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=tree;f=drivers/input/lirc;hb=HEAD

Note that lirc_zilog started out as a rename of the old lirc_pvr150 driver, which started out as a fork of lirc_i2c, maintained by Mark Weaver, with details on it in his blog. lirc_zilog has been updated for use with newer kernels and more devices though, while the original is only targeted at the PVR-150 and no longer builds on current kernels. Another thing to note is that kernel 2.6.31 introduced a ton of i2c changes, so the lirc_zilog from my git tree won’t work with kernels prior to 2.6.31 anymore, unless you back out the i2c changes.

Once you have the driver built, there are still a few more steps to get things working. Oh yeah. Note that if you’re running Fedora 12 and its latest kernel, you don’t need to worry about any of the above, I already patched all the necessary bits into the Fedora kernel.

Either way, you still need a firmware image, a config file and some scripts to figure out which config stanza you need. Mark’s page includes links to the ‘firmware‘, which is really just a signal lookup table, extracted from the Windows driver. This file needs to go into /lib/firmware/ or wherever it is your distro puts kernel driver firmware images (any sane distro, it should be /lib/firmware these days). At this point, you should be able to load the lirc_zilog driver successfully and without any oopses (I still need to make it so the driver doesn’t oops if the firmware image isn’t found…). To be perfectly clear: the transmitter cannot transmit arbitrary IR commands, only those for which there’s a mapping in this pseudo-firmware table. If your device isn’t in the table, its probably not going to work. At least, not without a newer lookup table. A recommended step to take if you can’t get it working is to try under Windows with the latest Windows driver, which may have a newer table. If that works, we’ll probably want to get that table extracted from the Windows driver and make it available for the Linux driver to use.

Again, we’ll defer to Mark’s page, which includes a link to an lircd config file for the IR blaster to get you started. This file contains config stanzas for every device supported in the binary-only lookup table (aka ‘firmware’) you’ve loaded into the driver. Download it, drop it into /etc/lirc/lircd.conf, and start up lircd. Now you need to figure out which config stanza is the correct one for the device you need to transmit IR commands to. At this point, you should also be able to run irw, and see key presses registered from the flimsy little grey remote included with the HD PVR. Anyhow, back to figuring out the correct device… For me, the simplest thing to do was simply look at the table Mark put together and pick out the closest match to my device — which is cable box codeset 85 for the Motorola DCT6200 (I actually have a QIP6200, but same difference). If its not obvious at a glance which codeset you need, grab Mark’s script to cycle through sending the power button code for each possible config until it happens upon the right one. Once you’ve found the right one, you can edit /etc/lirc/lircd.conf, and strip out all the codesets that *aren’t* the right one. The last step is to then wire up a channel-change script in MythTV for your HD PVR capture device to use. Once again, we turn to Mark, and his channel changer, which you’ll simply need to edit to make sure its using the right codeset.

If during the above, or any time after, you’re having trouble getting any IR transmissions to register, there are a few things to note. First up, the transmitter should light up with each irsend command. If yours isn’t lighting up, its not properly connected, broken, or the driver isn’t actually working. Second, the transmit range is REALLY short, the transmitter needs to be positioned quite precisely over the reception target, or its not going to work — even a few centimeters to the left or right of the reception target, and its probably not going to work.

Now for the big caveat emptor: I believe at this stage, very few (if any) people have been able to actually use the IR part on their HD PVR under Linux reliably. At some point or another, while in the middle of video capture, the device completely deadlocks, and has to be reinitialized. Looking into the root cause of this is on my TODO list, but its a long list…

Jan 17 2010

lirc fail in Fedora

Category: Fedora,Linux,Linux Infrared Remote Controljarod @ 11:04

Ugh. Seems lirc_i2c doesn’t like to work when running the latest Fedora 11 kernel. I fixed the problem in 12, but never got the fix into 11, apparently. And in the latest pushed update kernel for Fedora 12, lirc_serial blows up (while it works in 11). Prime example of why we need to finally get lirc upstreamed, dammit… Anyway, the latest Fedora 11 and 12 2.6.32.x kernel builds have *both* fixed, so if you need either/both, try updating to that — they may be in updates-testing, or you may have to grab them straight out of the Fedora build system, not sure right now…

Jan 17 2010

The lirc_mceusb/lirc_mceusb2 confusion

Category: Linux,Linux Infrared Remote Controljarod @ 10:17

Somehow, despite the fact it says in the lirc 0.8.6 release notes (and I quote):

* merged 1st-gen mceusb device support into lirc_mceusb2,
renamed lirc_mceusb2 to lirc_mceusb

And at the top of lirc_mceusb.c it says:

* Original lirc_mceusb driver deprecated in favor of this driver, which
* supports the 1st-gen device now too. Transmit and receive support for
* the 1st-gen device added June-September 2009,
* by Jarod Wilson and Patrick Calhoun

I also announced this merge on the lirc and mythtv mailing lists. And yet, people *still* keep asking for clarification on the matter. What’s not clear? Can’t people read anymore?

So one last time: Yes, lirc_mceusb2 and lirc_mceusb were merged into a single driver, now called simply lirc_mceusb. Yes, both the older and newer mceusb transceivers are supported by it. Yes, transmit (aka IR blasting) works on ALL of them. And yes, when I say all, that does include on both ports on the older v1 device. Clear enough?

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…

Jan 13 2010

Fun with remotes

Category: Fedora,Linux,Linux Infrared Remote Controljarod @ 23:30

So the Linux Infrared Remote Control project has been around for 10+ years now, with kernel modules that have never ever been incorporated into the Linux kernel. Back in September of 2008, I posted all current lirc kernel drivers on the Linux kernel mailing list (aka lkml). Got tons and tons of feedback, mostly things that needed fixing. :) (And this was after myself, Eric Sandeen, Janne Grunau and a handful of other people to a lesser degree, spent a bunch of time and effort simply cleaning up the code to meet kernel coding standards — see scripts/checkpatch.pl in the linux kernel source tree).

So anyhow, I said thanks much for the feedback (particularly that from Jon Corbet), but hold off on further reviews until we address everything brought up so far, and we’ll resubmit a smaller set of patches for the best of the drivers to keep from being overwhelmed (18 drivers at once was probably a bit much…). Fast-forward slightly over a year. Took way longer to get round two posted than I would have liked, but in October of 2009, I posted just lirc_dev, lirc_imon and lirc_mceusb. Largely no response for a few weeks, then an explosion of north of 250 emails over a couple of weeks bouncing back and forth about how we should do IR in the kernel…

Basically, there are two ways to do things:

1) decode the IR signal inside the kernel and map it to an input subsystem key, i.e. map the IR signal for the Volume Down key on your remote to the input subsystem’s KEY_VOLUMEUP.

2) decode the IR signal in userspace (using lircd) and do with it as you please (ultimately, you can do the exact same thing as #1, but it requires a userspace process and configuration).

So now, one camp insisted that in-kernel decoding was the only true way to do things, because then it’ll Just Work with no configuration required. Except when it doesn’t… See, many IR receivers can handle a myriad of IR protocols and work with nearly any remote control. And an IR signal of protocol X may map to key Y on remote Z, but protocol X may map to key F on remote Q. There is, of course, some low-hanging fruit, where we can set things up to Just Work for the default remotes for a number of receivers, but that winds up being a somewhat limited set of devices — and sometimes the same receiver can be bundled with different remotes. In short, its a mess trying to support everything Just Working. The other major issue on this side of the fence is that userspace decoding requires adding new kernel interfaces and/or significantly altering the existing ones to support IR.

The other camp insisted that in-kernel decoding was a horribly bad idea, and that it should always be done in userspace, mostly because of the aforementioned issues. You’ll just never always get it right, and making changes in userspace is easier for users (imagine that). This is the way lirc has been doing things for 10+ years. Which means, by now, most of the kinks have been worked out (outside of automagic configuration).

I like to play the role of diplomat. And I can see uses for both. So what I *want* to do is work towards a hybrid approach, where driver authors can have their devices support either in-kernel or userspace decoding, or even both, leaving it up to the user to pick which one they want (defaulting to in-kernel, of course, since it ought to be possible to make that Just Work for receiver’s stock remote). The lirc interface and userspace daemon has proven itself stable and reliable over the years, so that’s what we ought to move forward with as the way for doing userspace decoding — we can even feed key presses back into the input subsystem via uinput, if so desired. And for in-kernel decoding, we’ll need to add protocol handlers for at least the major IR protocols (RC5, RC6, NEC, Sony, JVC and a handful of others — see http://www.sbprojects.com/knowledge/ir/ir.htm for a wealth of information on various protocols).

I actually had the SoundGraph iMON driver supporting something of a hybrid approach when I submitted version two of my patches. However, the iMON devices (at least, all recent ones) do onboard decoding, so there isn’t actually any raw IR that can be passed to the lircd userspace, only already-decoded hex values. That being the case, I completely gutted the lirc_imon driver, and it now (at least in my git tree) only supports the really old iMON devices that do pass raw IR, while the recent iMON devices (found in many HTPC cases) are now supported by a pure kernel input layer driver called simply ‘imon’, which I submitted for kernel inclusion a few weeks back (need to get back on that, see if I can figure out what’s holding up it getting merged).

So next up on the docket, after a detour reworking lirc’s core kernel interface driver to support the new kfifo api in linux kernel 2.6.33, is to get lirc_mceusb and maybe one more driver back up to snuff, and submit a version 3 patch, this time for inclusion in the drivers/staging/ tree. There’s some concern that once we add the lirc device interface, it’ll be set in stone, but if we bring it in via staging, its implied that the interface isn’t yet set in stone, so we can alter it if need be. But again, its been around for 10+ years, so I suspect there isn’t much that’ll require changing.

The current work-in-progress stuff can all be found in the kernel git tree I maintain up here: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary.

Its also patched into the latest Fedora kernels. Now I just need the time to finish up that v3. And some more sleep.

Jan 13 2010

What’s new with you?

Category: Family,Linux,Red Hatjarod @ 14:11

Lots of things. My wife started blogging quite a while ago now to keep friends and family who we don’t see regularly up to date on what’s going on in our lives. She used to make snide comments about how stupid blogging was. Same thing with facebook and the like. Now she blogs and facebooks it up on a regular basis. I was kind of anti-facebook myself, but have found it a useful thing to find out who’s doing what where, particularly for people I don’t see that often. I live 3000 miles away from where I grew up, and plenty of old friends have spread out around all over the place, so its hard to keep up with ‘em all, without some sort of aggregator, if you will. Enter facebook. Mostly just use the mobile app on my iPhone, because its quick and easy to look through stuff wherever when you have a few minutes to kill.

I have a new job now too, starting a few months ago now. Same company, just new duties. I’ve taken over as the primary maintainer of the Red Hat Enterprise Linux 5 kernel. A whole lot more data management than actual development work, but very interesting stuff, and I do get to read over a ton of code all over the kernel. Finally actually regularly paying attention to the linux kernel mailing list too, though its mostly ‘skim and delete’, but I’ve also been heavily involved in a thread or three of late…

We’ve still got two kids of my own, haven’t managed to lose track of them yet. We’ve also got a foster daughter, who has been with us for well over a year (she’s ~16 months old now), who we’re quite likely to end up adopting, if things work out right. Of course, it means we’ll probably *also* end up adopting her older brother (currently 2 1/2-ish). As a fun anticipated side-effect, we’re gonna need a bigger house. We’ve been slowly working on numerous fixups around the house for well over a year now, trying to get the house into selling shape. Had the exterior repainted last summer, put in new tile in the kitchen, bathroom and hall about a year and a half ago, had new carpet installed in parts of the house a few weeks ago (complete with me having to replace some questionable subflooring), just installed a new range hood that actually matches the rest of the appliances we’ve replaced since moving in, etc. Fixing it all up just in time to move out! Whee, good times…

That’s all for now, I need to get back to working on, you know, work.

Nov 28 2006

Get away from me, door-monkey!

Category: Uncategorizedjarod @ 17:16

The post is a bit dated, but I hadn’t come across it (or even thought about it) until a friend pointed me to it today: No, You CANNOT Check My Receipt. And They Shouldn’t Check Yours. I’ll have to remember that next time I hit a store with door-monkeys… :D

Nov 28 2006

Of Rain and Snow, Seattle and Boston

Category: Baseball,Uncategorizedjarod @ 11:19

Okay, supposedly, it rains all the time in Seattle, and Boston is supposed to be covered in snow well before Thanksgiving. However, I think my mens league baseball team here in Boston had more games rained out this summer than in I had in all the summers playing in Seattle. Then, to make it more interesting, we still have no snow in Boston, and I turn on Monday Night Football last night to catch the Seahawks in action against the Packers, and did a double-take: Qwest Field in Seattle looks more like Lambeau Field in Green Bay, because its covered in snow. Snow in Seattle before Boston?!? Dammit, I want my white Christmas (so does Jamie), so where’s this New England snow everyone keeps yapping about?!? :)

« Previous PageNext Page »