Tuesday, June 8, 2010

More evidence that the Minister for Communications doesn't know how we communicate

I read an article in today's Age entitled Australia denies targeting Google over web filter. I find this comment by our glorious Communications Overlord to quite informative.

"It is possible that as Google drove past your home, if you didn't have the password protection and you were typing, you were doing your online banking, passing personal information in a transaction, as they drove past they could have captured that," Conroy said.

Informative that Conroy yet again has shown he doesn't get the internet. He's talking about the protection that your wireless router has. WPA or WEP or whatever else you're using. Which is fine to stop my neighbour downloading his pr0n off my network, but Mr Conroy that doesn't stop anybody else reading it when it goes down the pipe to the wider web.

"Oh no, my banking details - if only there was a scheme to prevent people reading my passwords". Enter the saviour of the piece - HTTPS. You see Mr Conroy when data of a sensitive nature is exchanged between two parties they encrypt it. Yes that's right, no bank in the world sends data in clear text. So even if Google harvests an exchange between you and your bank Senator - it's meaningless noise to them; they can't read it (at least without extensive effort/time/money). I dare you to find me the name of a bank that doesn't use HTTPS. I double dare you [insert line from Pulp Fiction] .....

On a philosophical note, if Google harvests data off a unsecured network then the person deserves to have Google exploit their location. People will only learn when they suffer.

Update: Check this out - /sigh

Friday, June 4, 2010

Linux Firefox 3.6.3 Tab Behaviour fixed

Something that's been annoying me for a while is how Firefox 3.6.3 on Linux now opens tabs next to the current tab you are in, instead of the far right.

This guy fixed it

Awesome

Thursday, June 3, 2010

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

Tuesday, June 1, 2010

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.

Monday, April 12, 2010

Sunday, April 4, 2010

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.

Saturday, April 3, 2010

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.