Remapping RaspBMC Remote Keybindings

I've updated my HTPC to be a Raspberry Pi that uses RaspBMC as the OS. The really hard part was integrating my existing RAID with the device (over USB) to serve up my media; that's a subject for another post.

Something that didn't quite work out of the RaspBMC box (and to be fair A LOT did work) was the Context Menu for XBMC. I like to call it the "right click" option if I was using a mouse. This was because my remote didn't have the default button that XBMC was expecting. As mentioned in a previous post I have a generic RC6 IR receiver that I had used the mceusb2 kernel driver. Looking at the remote config file for XBMC (/opt/xbmc-bcm/xbmc-bin/share/xbmc/system/keymaps/remote.xml) the ContextMenu is mapped to the <title> key. Looking in the LIRC config file for XBMC (/opt/xbmc-bcm/xbmc-bin/share/xbmc/system/Lircmap.xml) for a mceusb remote the "title" is mapped to the "Guide" key. Looking on my trusty remote diagram there was a Guide button, but why didn't it bring up the context menu?

Turns out that RaspBMC was using a different remote config in Lircmap.xml Using irw to see the remote codes I get:

16d 0 KEY_EPG devinput
16d 0 KEY_EPG_UP devinput

Searching Lircmap.xml for devinput I got a different <remote> profile, with no mapping for <title> So I added:

<title>KEY_EPG</title>

and the Context Menu is displayed.

Handy little util irw for figuring out remote config.

g-Cpan is my shepherd

The electronic TV guide for MythTV sucks! At least for Australia. I got put onto a little perl program called Shepherd. Basically "Shepherd provides reliable, high-quality Australian TV guide data by employing a flock of independent data sources." This is the good stuff! I read on about how Shepherd works and I was impressed enough to try it. The install instructions were pretty easy to follow. I installed version 1.4.0 Your mileage may vary with another version. If you're a Gentoo user you'll need the following mandatory packages installed for shepherd:

• dev-lang/perl


• dev-perl/libwww-perl


• media-tv/xmltv


• perl-core/IO-Compress


• dev-perl/DateManip


• dev-perl/Algorithm-Diff


• dev-perl/Digest-SHA1


• dev-perl/File-Find-Rule

The optional dependencies are listed on the Installation page, under Non-Distribution Specific They correspond to the following Gentoo packages.

• dev-perl/Archive-Zip


• dev-perl/DateTime-Format-Strptime


• dev-perl/Crypt-SSLeay


• dev-perl/GD


• dev-perl/HTTP-Cache-Transparent


• dev-perl/HTML-Parser


• dev-perl/HTML-Tree


• dev-perl/IO-String


• dev-perl/XML-DOM


• dev-perl/XML-Simple


• perl-core/Digest-MD5


• perl-core/Storable

However a mandatory dependency, List::Compare doesn't have a portage ebuild. The Shepherd page linked to a tool I'd never heard of before, g-cpan. g-cpan sits on top of CPAN, but builds ebuilds in your overlay, and installs the perl module in a Gentoo-esque way. If no overlay is present in your /etc/make.conf, the overlay will go into /var/tmp/g-cpan. My overlay is set to /usr/local/portage because I don't like the thought of ebuilds ending up in a temp directory. Running

$ g-cpan -i List::Compare

installed the needed perl module. Very nice. I couldn't find an ebuild for the optional JavaScript.pm module, so I used g-cpan for that as well.

Note for the JavaScript.pm install make sure that you setup up spidermonkey in the right way, otherwise the module wont install properly.

$ emerge spidermonkey
$ mkdir /usr/lib/MozillaFirefox/
$ ln -s /usr/include/ /usr/lib/MozillaFirefox/

While running the Shepherd install, I encountered a few errors.

1. No mysql.txt Not sure how this file is created. I think it's a mythfrontend config file to specify how to connect to the backend. It's contents looks like:

   
   DBHostName=$HOSTNAME 
   DBUserName=$USERNAME
   DBPassword=$PASSWORD
   DBName=mythconverg
   DBPort=0

   My suspicion is that since I'm using XBMC, this never got created. I created one in ~/.mythtv for the user that I run XMBC (and shepherd) with, and reran shepherd.


2. Creation of the tv_grab_au symlink. If your user doesn't have sudo rights - which is a valid security situation, this will fail. Not hard to do yourself, but I wonder if Shepherd should assume sudo rights.


3. Addition of Shepherd cron job to crontab. Failed due to lack of sudo rights. To do yourself (as root)

   $ crontab -e
   [Add crontab entry and save file]

   If you didn't get the crontab output from Shepherd, I put

   56 * * * * nice /usr/bin/mythfilldatabase 
     --graboptions '--daily'

   into my file (all as one line).

If you ran shepherd without installing the optional modules, you can rerun the install process using:

$ ~/.shepherd/shepherd --configure

Shepherd hasn't run yet, (the --history flag tells me so), I'll wait for an hour or so. Overall I'm pretty impressed with Shepherd so far. It's well documented, the installation process is easy, and provides good information to make decisions. Keep up the good work Shepherd dev(s).

MythBox is the key - not Asia

Apologies to any readers who don't play Risk for the post title.

I'm up to the stage where I need to get the recording functionality working. That was the major selling point to my wife. So I bought an Aver Media DVB-T 777 second hand from eBay on the recommendation of a mate. The reason he has it, and that he suggested it to me, was that it plays nicely with Linux as the Phillips SAA7134 chipset is well supported in the Linux kernel. I'm currently using version 2.6.31-gentoo-r6, with this config

Device Drivers
  --> Multimedia Support
    <*> Video For Linux
    <*> DVB for Linux
    [*] Video capture adapters -->
      <*> Phillips SAA7134 support
      <*> Phillips SAA7134 DMA audio support
      <*> DVB/ATSC Support for saa7134 based TV cards

Compile, reboot, and done. TV card supported.

I emerged media-tv/mythtv-0.22_p23069 and followed the instructions on the MythTV wiki for configuring the backend.

When running mythtv-setup, if all you have is a keyboard, the left and right arrows allow you select options from combo boxes, the up and down arrows select combo boxes, buttons, text fields, etc and ENTER/RETURN selects whatever is highlighted. You'll get the hang of it.

When selecting your capture card, make sure that you select the DVB under the card type. In the case of my card, because I had multiple inputs (there's an S-Video adapter) I didn't change the card type, so I spent a lot of time figuring out what I couldn't scan for channels. The DVB "section" of your card is the antenna port.

Once you quit mythtv-setup and run mythfilldatabase, if you get an error about not being able to create a QObject/widget start your backend again. This is a weird error with not much information to go on, and took me a lot of googling to figure out. It's because the backend can't be connected to, so starting it solves the problem.

Once I got MythTV configured, it was time to check out how to integrate it with XBMC. The inbuilt stuff to connect to a MythTV backend is buggy, causes XBMC to lock up, and isn't very feature rich.

However MythBox is the saviour of this piece. Has everything the wife would want. So I'm testing the recording abilities now, and can watch live tv. Once I do some more tweaking I should have a decent PVR in the HTPC.

I really do need to get a new HD though.

Progress on Evergreen open source drivers

In my HTPC I'm using a Radeon 5450; but since the 5450 is based on the Evergreen chipset I've been using the propriety drivers (x11-drivers/ati-drivers). Not a fan.

However since the Linux Kernel 2.6.34 release, it appears that progress is really coming along on the open source drivers (see point 1.11 in the link). I look forward to ditching flgrx soon. :)

HTPC tweaking

I fixed my XBMC problems

1. My XBMC hanging/screen issue is fixed by turning System->Video->Playback Sync playback to OFF.


2. My sound popping issues were fixed by turning the System->Video->Video Blank Sync to ON.

I discovered how to use a handy little util called ddcprobe which is part of the xresprobe project. It helps figure out what modes, refresh rates, etc, your monitor/card supports. Great for filling out your Xorg.conf :)

For some reason the ddcprobe as part of Xorgautoconfig doesn't work properly (I kept getting segfaults), so get the source and build it yourself.

Some TV tweaks, and I'm done. If only the TV wasn't busted. My next step is to put a capture card in, because my wife hates missing her soaps :p

To boldly go where ....

It's been a while since I wrote anything HTPC related. The reason is that I set up the HTPC as best I could, but I didn't own a HDTV. Until last Saturday (29/05/2010) when I got a Samsung 40" LCD. However after 6 hours out of the box, it breaks. :( :( :( One of the panels started distorting the picture. I'm in the process of sorting out a replacement.

However it does give me something to try out the HTPC on. Boot it up, and lovely XBMC appears. Some config tweaking and voila, full HD playback.

All is not well though.

I did a portage upgrade and amongst other packages the ati-drivers got upgraded to 10.5. Now I have a problem with XBMC hanging when I push stop on the remote. I've posted to the XBMC forums if anyone has any ideas. I tried downgrading to 10.2 but got blocked (see this forum post)

While investigating the above issue, I also found (IMO) a borked ebuild for XBMC for xbmc-9.11-r4. I had 9.11-r3 installed and I thought upgrading to 9.11-r4 might fix my blank screen problem. Seems 9.11-r4 has a dependency on Python 2.4, when the rest of Gentoo (at least on my boxes) is using 2.6 Looking into this it's because the XBMC scripting engine is 2.4 based. There's a Gentoo forum post on the matter. Why the ebuild is borked is because (from the associated bug report)

If I understand the problem correctly, than its not a matter of the python-version. Xbmc has made a few patches/additions to python, which aren't upstream. The included python has this patches, python as an external library misses this features.

So putting a dependency on an external 2.4 python interpreter WONT EVEN FIX THE PROBLEM

What should be done is to incorporate the suggestion made by comment 12 in the bug report into the ebuild. As comment 15 pointed out, having an external python 2.4 interpreter will fix somethings, but not everything, where as using the bundled interpreter with XBMC will ensure all plugins working (as far as the infrastructure is concerned).

I updated my xbmc-9.11-r4 ebuild and it built fine. Doesn't fix my XBMC hanging problem though.

Autostarting HTPC

As mentioned I've got a dummy user set up on my HTPC box (tvuser) that needs to autologin when the machine boots up. Reading this gave me an overview of what needed to be done. I edited my /etc/inittab to change

c1:12345:respawn:/sbin/agetty 38400 tty1 linux

to

c1:12345:respawn:/sbin/agetty 38400 -l /sbin/autologin.sh -n
tty1 linux

where /sbin/autologin.sh looks like

#! /bin/bash
exec login -f tvuser

Note that the inittab entry should all be on one line (I had to put a line break in there for formatting), and the autologin script has root permissions, so only the bootup sequence (or me as root) can execute it. I previously was using fluxbox as my window manager since that's what I use on my laptop, however it was time to get XBMC going.

 emerge -vDp xbmc

did the trick. I then altered tvuser's .xinitrc to contain the line

exec xbmc

To make sure that X is started when tvuser (auto)logins, I set the following in tvuser's .bashrc

if [ "`tty`" = "/dev/tty1" ] ; then
  startx
fi

The conditional helps because when I was debugging some config by sshing into the HTPC as the tvuser user, X kept trying to start. The conditional has X only start of the tty value is /dev/tty1 which only happens as boot time.

The remote works so far with XBMC, however I haven't tried anything too exotic.

The boot process is a bit slow for my liking. I've got some other boxes that could do with a boot boost, so I'll probably take the time now to research how to reduce the bootup time of my Gentoo boxes.

cat /dev/lirc0 > brain (getting LIRC working)

Due to lacking some hardware, I've postponed the connection of the HTPC box to the telly. So I thought I'd conquer the remote control problem. When I bought my laptop I got given a whole bunch of stuff that I thought I'd never use. Part of which was a remote control and an IR receiver. Very handy now. I looked up the LIRC Gentoo Wiki to get some idea of what I was needing to do. Turns out it wasn't so simple. My IR receiver plugs into the USB port, so I thought I would use the devinput LIRC_DEVICES option. Turns out that was a bad idea. I couldn't get irw to ouput any codes. I thought that maybe it was because I had a very empty mapping section in my /etc/lirc.conf So I tried using irrecord. That didn't work either. irrecord kept informing me that I wasn't pushing the button when my finger and the two red LEDs on the remote and the receiver seemed to suggest otherwise.

My next thought was that there was a problem with the USB subsystem. So I checked I had all the right stuff in the kernel. Tick. So I googled around for how to find out what's connected to the USB. Handy little program lsusb. It told me that I had a "Philips eHome Infrared Receiver". Checking the dmesg logs at /var/log/dmesg showed nothing wrong with the USB side of things. So what was going on?

Google once more to the rescue! Turns out that I had compiled the wrong LIRC driver (or no driver at all). Changing my LIRC_DEVICES to mceusb2 (and reemerging lirc) compiled the correct driver /lib/modules/2.6.31-gentoo-r6/misc/lirc_mceusb2.ko modprobing lirc_mceusb2 created /dev/lirc0 Testing it via irw I got some results

000000037ff07be9 00 Play mceusb

All that was left was adding the kernel module to /etc/modules.autoload.d/kernel-2.6, and adding lircd to the default startup sequence and I was done. A quick reboot to ensure that everything worked from the get go, and I had a working remote control. Turns out the running etc-update after reemerging lirc updated my /etc/lirc.conf with a config file for generic RC-6 remote; which is handy because on the bottom of the remote it's labelled "RC6" ;). It's nice that the ebuild for lirc copies the config for you upon install. Not hard to do it myself, but I like the ebuild doing the heavy lifting for me :)

Now I have to do some config to make sure that apps can respond to those bathroom break pauses during the extended Lord Of The Rings sessions :p

Update: next time I should check the Hardware4Linux site. Might save me some troubles.

Quick X update

With some reading of the xorg.conf man page (man 5 xorg.conf) and the xorg.conf.example file I got X working with fluxbox. I created a dummy user (tvuser - how imaginative) with very little permissions (not part of the users group, can't su/sudo, etc) to autologin and start X. I also created an admin user so that I can start to tighten up security.

Since I use ssh mainly to log into the box (so I can type from my laptop keyboard where the multiple Firefox windows are) I configured SSH to do X forwarding. I use fluxbox as my window manager on my laptop; so after emerging it I scp'd all my files from my .fluxbox directory to my users directories.

I do not think that word means what you think it means

Ah the joys of tracking down documentation, help, and that tiny bit of information that makes it all click :)

I got a base Gentoo Linux install onto my HTPC box, with kernel version 2.6.31 That was the easy bit. The hard bit is figuring out how to get my video card drivers running.

Gentoo is great with the helper guides it provides, and if any doco writers read this - keep at it. The Hardware 3D Acceleration Guide and The X Server Configuration HOWTO guides have been very useful. However there are a few things to note that weren't apparent to me straight away; and that I burned some time away on. The first is the keyword differences between the propriety ATI drivers (from here on referred to as fglrx) and the open source drivers. Two are provided 'radeon' and 'radeonhd'.

In Gentoo to specify the drivers for X, you edit the VIDEO_CARDS property in your /etc/make.conf However adding radeon and radeonhd will get you the open source drivers. Pretty obvious now, but without knowing how the keyword fglrx aligns to my Radeon 5450 video card, I went down the wrong path for a bit. Easy to recover from. I updated the kernel to rip out all references to video card drivers, and DRM. I unemerged all the unneeded x11-drivers packages and updated the VIDEO_CARDS flag to contain fglrx vesa. The vesa keyword is handy for a plain old backup driver. Ran an

emerge -vDNu world

and all is well. To make sure that the fglrx module was loaded at boot, I added fglrx to /etc/modules.autoload.d/kernel-2.6

The next problem came with trying to get X running. Can't watch those DVDs without it :). It's nice that the writers have added in the relevant steps for getting HAL working with X (the Xorg package in particular). When I first upgraded to Xorg 1.6 on my laptop, all the input devices stopped working, and Xorg 1.6 passes the management of that stuff to HAL. I guess I'll have to be careful when that all moves into udev.

Running the

Xorg -configure

command didn't work. I kept getting this error.

(WW) fglrx: No matching Device section for instance
(BusID PCI:0@1:0:1) found

After some searching on the Gentoo forums I found this helpful post outlining that

Since your using the ati-drivers , don't use Xorg -configure , you
want to run 'aticonfig --initial' ... That will set up
your xorg.conf the way fglrx needs it.

So ATI couldn't play nice and do things the same way the rest of the community does it? I ran it and got a basic xorg.conf I'll have to do more work to polish it off, but I'll soon have X running (I hope).

I got thinking to myself, why should I bother with the propriety drivers since there seems to be a decent community around the open source version. Maybe I should ditch fglrx and go with radeonhd. Alas I don't think I can. According to Wiki the 5450 uses the Evergreen chipset, and it seems that the radeon and radeonhd drivers aren't there yet; which I can understand given that the chipset is new.

Now all I need is to get X to work on the TV properly and I can move on to XBMC.

Let the HTPC games begin

I had to wait a couple of weeks for my Video Card to arrive. I called most major vendors around and they all gave me the same time frame. There must have been a cargo container sitting on the docks with everyone's card in it :p

It arrived in the mail yesterday, and I plugged it in and turned on the machine for the first time. It didn't have any onboard video so I had to wait for the card. But now I'm off and running; installing Gentoo as my OS. I then plan to install the Radeon drivers and setup all the power saving features like the AMD CPU 'Cool n Quiet' to stop my power bill going through the roof.

I'm glad it's Saturday tomorrow :)

So you want that new Video Card

Something I'm planning on doing is making my own home theater PC. I've also got some code that takes a while to compile so I can double the box as a massive compiler to make use of those extra CPU cycles. My old man has recently upgraded, and I got his old box. However he decided to keep his video card. I've been looking at the Radeon 5450 since it's been getting some great reviews as a HTPC card.

However I'm planning to use XBMC as my front end, on a Gentoo Linux OS. So I need Linux drivers. Are they listed on the AMD drivers page. Nope. Does googling around find them. Nope.

I did find a review of the card which was benchmarked under Ubuntu. So after some posting on the forums turns out that the Catalyst driver bundle will work with the card.

I have yet to buy the card, so I can't say for sure. But I do feel a lot more confident now.

Oh and AMD - please actually update your release notes when you put out new cards. If it's not in the release notes under the supported cards section, then how are consumers meant to know other than trial and error.