For those of you who were following my MythTV saga from a few posts ago, I am happy to report that as of tonight, all the buttons on my remote control now work from within MythTV. How much work required though really offers some more insight as to how badly broken usability in Linux is.

Originally, I thought I would be able to take advantage of the fact that the kernel knows what remote control ships with the device and is automatically generating input events by default (assuming you remove the cx88-ir driver from the hald blacklist). So for example, when I hit the “Channel Up” button on the remote, a KEY_CHANNELUP input event was being generated. Unfortunately, MythTV doesn’t understand any of these input events that are Linux specific. Myth relies on a table of input events provided by the QT library, which provides a common portability layer (at the cost of only offering the lowest common denominator). Hence, even though my remote control was detected by the kernel, and unique events were being generated for each key, there was no way for MythTV to identify the events.

I could probably make it work if I were willing to extend the MythTV source to know how to handle non-standard events (and I might still do that in the future). If such work were done, MythTV would start to “just work” with all of the remotes that are shipped with tuner products by default.

So I ditched that idea and figured I would go with the lirc approach. When I had tried running “gnome-configure-lirc” previously, it had failed to show my cx88 card in the list. But now that I had removed it from the hald blacklist, now it showed up properly. I selected the cx88 and specified the “Hauppauge silver/black remote” I had kicking around.

I saved the configuration and exited the program, but at that point the lircd service would not start, claiming that it could not load the kernel modules. It turns up the default lircd configuration file specifies two single quotes (”) as the name of the modules to load, and says that loading of the lirc kernel module is required, even though my device uses the inputdev interface. Edit the configuration file to say that no modules need to be loaded, retry, and find that now it’s complaining that it cannot open device profile (”), since the gnome-configure-lirc also doesn’t bother pointing lirc at the remote control configuration I had just created. More edits to the configuration, and now the lircd daemon *finally* starts.

I run the “irw” test utility and start whacking buttons on the remote, and it is showing the correct info for *most* of the buttons. However, several buttons fail to register at all, like the “OK” and “Back/Exit” button, both of which are fairly important. So now I’m running “irrecord”, a handy little command line application for mapping buttons to keys that, from the crappy usability, you would think was written by a twelve-year-old. You’re expected to know the exact names of the input mappings in advance, or else you have to run “irrecord –list-namespace” in a separate window to dump out the list. Oh, and it doesn’t do incremental updates properly so if you run the program twice it proceeds to trash out whatever keys you defined previously (forcing you to output to a temp file and merge the results by hand with a text editor).

It’s worth noting that the remote control profile setup by gnome-configure-lirc *does* have mappings for the buttons in question – they just don’t match what is actually being generated by my remote control for whatever reason.

I get past *that* point and now irw is showing the correct buttons, but MythTV doesn’t work still. It turns up at some point “mythbuntu-lirc-generator” got run, creating a profile based on a different remote control. It’s not quite clear to me what sort of black magic this program does to setup MythTV, but after digging through the frontend logfile it became clear that I needed to run it again.

In total, I spent about 90 minutes fumbling around before I finally got it all to work. There is clearly considerable room for improvement in this process. In fact, one might argue that it’s pretty pathetic how much work was required given it’s an extremely popular card and I couldn’t even get it to work with the stock remote that shipped with it.

At least my fiance can now finally use the MythTV box in my living room without having to know the esoteric commands like how the left and right bracket [] keys on the keyboard control the volume.

I know things have been pretty quiet on the blog lately, so I wanted to give you all a quick status update on how various projects are going (for better or for worse). We are quite busy, but alot of the stuff we are working on is not currently publicly visible, and many people who read the blog are interested in various things we are doing in the open source community (either out of academic curiosity or because you own some piece of hardware that you are hoping to see better support for).

So, let’s talk about the stuff that we are actively working on first:

em28xx quality fixes – I spent most of this week trying to nail down a significant quality problem in em28xx analog support. I did isolate one problem, but I am seeing other issues that bother me. The current fix is here:

http://kernellabs.com/hg/~dheitmueller/em28xx-test/

While I was at it, I nailed down a regression that got introduced that resulted in the xc3028 firmware taking nearly five seconds to load (whereas it used to take about 1 second). This is probably most noticeable by users of devices such as the original HVR-950 (em28xx/xc3028) where it resulted in applications like tvtime and MythTV taking *much* longer to startup.

http://kernellabs.com/hg/~dheitmueller/xc3028-regression/

tvtime – Tvtime work has been slower going than I would have liked. I did do some work last week, but the more testing I do the more problems I find. The goal at this point continues to be to get a release where both the audio and VBI support work well with a variety of cards, and then ask the distributions to redistribute this version.

HVR-1600 ALSA support – There were a bunch of cleanups required to get this upstream, but I am happy to announce that it was merged this week. None of the changes asked for were actually necessary for the driver to work – all of them were codingstyle issues.

http://kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-3/

Now, let’s talk about the things I’m not working on right now. This list is based largely on the comments I receive both on the blog and via email where people ask “When is X going to start working?”. I feel there is some value in telling everybody about this stuff, so that expectations are set properly and in case anyone else wants to contribute (knowing that we are not actively working on it).

HVR-950Q work with MythTV – Ok, so I was the guy who wrote the analog support, and I did do some work a couple of months ago to at least getting it basically working with MythTV (with a few well-documented caveats). But as at least one user has pointed out, there is some sort of race condition where the card gets locked up periodically when switching back and forth between analog and digital. If you use it for digital only then you are fine, or if you use it for analog only then you are fine. But if you try to use it for both then you are in for trouble.

HVR-900R2 and PCTV 330e – I’ve discussed this particular issue various times in previous posts. Basically it boils down to getting an extraction script written for the firmware, and fixing the existing driver to work with the updated firmware (since the firmware that was used to write the original driver can not be found). You can read the blog history for the gory details as to why something that sounds as simple as a firmware extraction script would end up being such a headache.

PCTV 340e/340eSE/801e/801eSE analog support – At this point, I have no plans to be extending the dvb-usb framework to support analog, which is what would be required to get analog support working for any of the dib0700 based devices named above.

saa7164 analog support – This is basically the same situation as with the dib0700 – it requires a *huge* development effort that would amount to hundreds of hours of labor. Sure, we might come out with something at some point if a commercial backer steps up, but I would not expect to see this supported in the immediate future.

I realize that the above list of “stuff we are not working on” can be frustrating if you are a user who was hoping to see one of these things done sooner. Let’s not forget that all of these are projects that KernelLabs developers are doing in their own free time for no compensation. We’ve donated thousands of hours to making LinuxTV better. And when it comes to the stuff we do in our free time, we need to focus on the things that interest *us* personally in order to keep our sanity. Unfortunately, the stuff I may be interested in “playing around” with is often not the stuff certain groups of users would prefer we spend our time on.

It’s probably also worth noting that we do see people who post comments in the blog along the lines of “How about accepting donations? I would donate $10.00 to see XYZ working.” However, at this time we are not accepting donations toward any of these projects. Why? Because there is *nowhere* near enough people who are willing to donate to make it worth our while – and it wouldn’t be fair to accept your donations but not deliver. I do appreciate those people who offer to donate, but unless you can find 1500 more friends like you, you are in an extreme minority. I have had extended conversations with a few individuals who argue that our view is not valid, but ultimately it is our decision what we dedicate our efforts to.

To end this post on a positive note, if you are a PCTV 74e user who has been looking for driver support, keep an eye on the blog since I’ve got a GPL driver and have worked out the firmware redistribution rights with the chipset vendor, so I just need to do some cleanup and testing before we can post a tree for testing.

Our new (previously owned) analog signal generator arrived tonight (a Promax GV-698/11):

Now, you might say “analog is dead” or “who cares about analog now that television has gone digital?” And the answer would seem to be “lots of people”. The reality is that as much as we like to talk about the advances in ATSC, ClearQAM, and the DVB variants, a large number of people out there still have analog and expect it to work. In the United States, the problem is especially evident since there are very few ways to access cable television without a settop box, meaning those people who do not wish to have an HD-PVR probably have a cable box connected to a tuner via an analog output.

Having a generator will make it easier to do testing of international standards (something that we do quite a bit of nowadays), and this generator in particular supports a variety of audio standards as well as teletext, meaning we can be confident that those functions will work even when we do not have access to a local signal source.

And finally, I personally have been quite dissatisfied with the general quality of a number of the different tuners and video decoders that I have worked with under Linux. Having a well calibrated signal source with a variety of patterns will allow me to improve the general picture quality for those devices. Whether that means making sure the registers for hue/saturation/contrast are properly programming, or being able to spot problems with formatting, resolution, or geometry.

It’s really easy to look at a TV picture and say “that doesn’t look right”. But figuring out what is actually wrong about the picture and what needs to be tweaked to fix it requires the right tools.