Of Myths and Mandatory Internet Censorship

A very informative article on the subject. Unlike Senator Conroy's uninformed propaganda.

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.

Writing config for LIRC

In my previous post, I got LIRC working with Gentoo. However the LIRC config comes in essentially two halves. The first is the mapping of the remote's IR frequency/signal to "buttons". So when I press play, the computer realises that I mean play. However how does the application know I mean play? That's where the second config comes in. It maps the buttons provided by LIRC (eg: Play) to application commands (eg: play <filename>). However there were two things I found while doing this that I thought were interesting.

Firstly, you have to put in the exact ASCII code into your app config that is emitted by your remote. Which is OK (and obvious), but occasionally you have pairs like Replay/Skip. Plus is VolUp Volup? Since I have a terrible memory I created a button diagram [PDF] that lays out the buttons and their ASCII codes. I created it using a photo of the remote that I took (I'm no photographer but it's usable), and GIMP/Inkscape. I prefer working with Vector graphics.

The second is that I found the LIRC config format to be very verbose and repetitive. With a large amount of config I could see it being difficult to understand what's going on. So I created my own (non sanctioned) meta syntax and a Perl script to turn that meta syntax into the proper LIRC config syntax. For example, take VolUp for mplayer

  begin
    remote = mceusb
    prog = mplayer
    button = VolUp
    config = volume 1
    repeat = 1
  end

The first three lines are going to be same for all the mplayer configs. It's the button, config and repeat options that are the interesting items for the VolUp command. In my meta syntax

# 
# The meta syntax is <, configvalue>*<; repeatvalue>*
# That is the button name with config values separated by , and
# repeat values separated by ;  The script will read everything
# between the separators and assign it to the appropriate
# key/value pair (eg config)
#
# Meta tags are fields that apply to the entire output
# (LIRC config) and currently stand as
# @prog - The program you are writing the config for
# @remote - The remote name
#
# The input may also contain comments (lines starting with the #
# symbol) to comment out buttons that may not be applicable to a
# program.
#

For the above example in the metasyntax I wrote

VolUp, volume 1; 1

Much more understandable (once you know what the separators mean of course). Coupled with the meta tags and the script, I generated an entire config for mplayer.

One could quite easily put different programs configs expressed in the LIRC meta syntax into different files which could then be run through the script and cat'd together into ~/.lirc which is where programs like mplayer and gxine, etc look for remote control configs.

All the files linked are licensed are essentially free. So do use them, play around with them if they will help you.

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 :)