Just a heads up in case anyone else’s Logitech Performance MX starts acting up on the middle mouse button: The switch used is an E-Switch TL3315NF160Q.
Apparently sometimes a drop of hot-glue is enough, but in my case the switch itself was broken. The linked tutorial does give clear instructions on how to reach it though. If you’re handy with a hot-air gun, it’s easily replaced 🙂
For the past couple of months I’ve been running XBMC on a Windows 7 installation. Worked pretty much instantly after installing, but the boot times were horrible, and every now and then windows updates would nag. When I bought the box I briefly tried XBMCBuntu, but concluded that it was too much tinkering to get it working and gave up.
However, today I set out to give OpenELEC a try. Almost everything worked out of the box, except for audio over HDMI. I’ve tried most of the things on the wiki, but couldn’t get it to work in both the video as well as the XBMC menu. Most people seem to be satisfied with just the video, often calling the XBMC menu sounds “obnoxious”, but I’m rather fond of those, so I set out to fix it.
Here’s a quick guide on what I did.
Continue reading OpenELEC on the Asus AT5IONT-I with sound over HDMI
I bought a Raspberry Pi to work together with my rooms moodlight. The current system uses an FTDI USB to RS485 converter cable with a full-blown linux PC pushing 1Mbps of data over that to drive the animations. I intended to replace that system with a Raspberry, seeing as it already has a UART on-board and would only need a small RS485 chip to drive the bus.
Unfortunately, out of the box the Raspberrys UART can only push 115200baud, and it spits out a shitload of debug data on the serial lines.
Here’s what I did to allow it to use the UART for other things, and to drive the UART at 1Mbps 🙂
The limiting factor on the UART speed is that UART Clock. It only allows baudrates of UART_CLK/16, and the clock is set to 3Mhz by default, limiting it to 187500baud. To drive 1Mbps, we need a UART-clock of at least 16Mhz. To do this we need to:
This should then allow you to set the baudrate higher, to test run ‘sudo stty -F /dev/ttyAMA0 1000000’. If that runs without problems, it’s probably OK. You can test some more with ‘sudo bash’, and then ‘echo BOO > /dev/ttyAMA0’ and see if an attached FTDI device picks it up at 1Mbps.
Next up is making sure nothing else is using the serial line.
Done! Now all that’s left is writing code to actually push something over that line and wire up a small rs485 chip 🙂
XBMC was supposed to work out of the box with the Media Center Remote, but for me it never did. Apparently this is because in linux kernel 2.6.something they merged some of those drivers into the kernel, X started handling them, and stuff like that.
To get it working, I had to take the following steps, most of which came from or were based on a thread on the XBMC forum.
Normally the up/down keys seem to work, but that’s only because X11 is treating the remote as keyboard input and is channelling the arrow keys properly whereas the other keys are a mystery to XBMC. Although it would be possible to bind all the other keys manually, I’d rather use XBMC’s normal way of doing this, namely through lirc. So the first step is to get X11 to *not* do anything with the remote input.
To prevent X11 from handling the remote input, add the following lines to /etc/X11/xorg.conf:
Section “InputClass”
Identifier “Remote”
MatchProduct “Media Center Ed. eHome Infrared Remote Transceiver”
Option “Ignore” “True”
EndSection
Then we need to get lirc up and running, so first let’s install it:
apt-get install lirc
Next we need to tell lirc what device the remote is on, seeing as the new kernel driver doesn’t use the normal /dev/lirc but /dev/lirc0. Edit /etc/lirc/hardware.conf and change the following three lines (just find the line where everything before the = is the same)
DRIVER=”default”
DEVICE=”/dev/lirc0″
Then we need to load the mceusb config file shipped with lirc:
cp /usr/share/lirc/remotes/mceusb/lircd.conf.example /etc/lirc/lircd.conf
At this point you should restart lirc with:
/init.d/lirc restart
And then try running
irw
and pressing some keys on the remote. It should give some output. Note that the ^]B like output is output generated by the kernel for the arrow keys. Try the big “OK” button to be sure, I’m fairly certain that the kernel doesn’t map that one. Ctrl+c out of this when you’re ready testing.
Finally, XBMC expects the MCE driver to give slightly different output. To fix this, we should print or open on another computer the file/etc/lirc/lircd.conf and open /usr/share/xbmc/system/Lircmap.xml. Then for each item in the <remote device=”mceusb”> section, change the middle bit to something from the lircd.conf file. For example:
<play>Play</play>
should become
<play>KEY_PLAY</play>
After you’ve changed all those and restarted X and XBMC, it should be working.
Finally because I wanted the box to sleep when pressing power instead of shutting down completely, I opened /usr/share/xbmc/system/keymaps/remote.xml and changed the line:
<power>XBMC.ShutDown()</power>
to
<power>XBMC.Sleep()</power>
Now I had actually thought to be done by now, but after a few tries it seems the computer randomly shut down sometimes. This was caused by the new kernel drivers also passing all keypresses to the input subsystem, and the input system deciding that KEY_POWER really meant KEY_POWER. To fix this, add the following line to /etc/rc.local, preferably at the start.
echo none +lirc > /sys/class/rc/rc0/protocols
This will tell the kernel to not attempt to decode the IR signal using any protocols, but instead only send it on to LIRC.
I finally figured out how to install a mostly working XBMC system on my new media center, a shiny Asus AT5IONT-I board with 4GB of ram.
Because it was quite a hassle, here’s the guide on how I did it, hoping that other people might benefit from it, and possibly myself too if I ever forget this when I need to reinstall 😉
First things first, a quick overview of what I’ll be installing. I’ll be using Debian wheezy, or testing currently, with XBMC from the www.debian-multimedia.org repository.
We’ll start by inserting the Debian Wheezy CD and starting the installation. It’ll complain about firmware for the network interface, just hit continue on that, we’ll manage that later.
When asked about which software to install, untick everything but the the SSH server (as that will make it much easier to troubleshoot if something goes wrong). You could possibly also add the Standard System Utilities, but I didn’t as I wanted the system to be as lean as possible, and if I needed anything specific, I could just apt-get it.
From here on, most of the configuration can be done either through SSH, or through the terminal (ctrl+alt+f1 after we’ve installed the graphical bits)
Once Debian is installed and running, the first step is to get audio working. Why audio? Because it’s a bitch to get working on this motherboard, and I’d rather know sound is working before I install any other parts. So on we go, installing alsa and pulseaudio:
apt-get install pulseaudio alsa-base pulseaudio-utils alsa-utils
At this point, audio should be able to play through the analog channels (over the Intel chipset on the board), but HDMI is still a bitch to get working (it’s possible, just more difficult). The problem seems to be that the nVidia chipset should have only one output (HDMI), yet due to some driver issues multiple are recognized. To fix this, we need to set some module options on the HDA Intel driver. For other boards, see the XBMC guide on setting up HDMI audio for NVidia ION and other cards. For my card, the you need to add the following line to /etc/modprobe.d/sound.conf using, for example, nano /etc/modprobe.d/sound.conf:
options snd-hda-intel enable_msi=0 probe_mask=0xffff,0xfff2
Then type:
modprobe -r snd-hda-intel
modprobe snd-hda-intel
aplay -l
The first two commands will unload and reload the intel HDA driver, the second should lits all audio devices. At this point, there should be two device on card0, one analog and one digital, and just one device on card1, the HDMI one.
Now to actually test HDMI, we need the nvidia drivers (and X11) to be loaded. First, open /etc/apt/sources.list and add the words contrib and non-free to each of the sources. Then type:
apt-get update
apt-get install nvidia-glx nvidia-xconfig xorg
nvidia-xconfig
Seeing as apt is now again whining about the missing firmware bits, this is also a good time to fix that:
apt-get install firmware-realtek
For some reason, the nvidia driver won’t properly load unless the system is restarted, so let’s do so now.
shutdown -r now
Now let’s get to installing the actual XBMC packages. open /etc/apt/sources.list and add the following line:
deb http://www.debian-multimedia.org/ wheezy main non-free
Then do:
apt-get update
apt-get install debian multimedia keyring
apt-get update
And finally install XBMC:
apt-get install xbmc-standalone
Finally we need to have XBMC start when the machine boots, for which I’m using this solution. Simply edit /etc/rc.local and add the following line just before the exit line:
su – xbmc startx &
And then make xbmc the window manager with:
ln -s /usr/bin/xbmc-standalone /usr/bin/x-window-manager
And finally allow XBMC to actually start the X daemon, by running
dpkg-reconfigure x11-common
and specifying that Anybody can start it.
At this point you should try another reboot and see if XBMC starts by default. Now to get sound through HDMI, we’ll have to set it up in XBMC. Go to System -> System -> Audio Output and
This should make video and music go through the proper channel. Test this by starting up a song or movie, and seeing if you hear anything. If you don’t, start alsamixer and play around with the volume controls. I needed to press F6 to change to the nvidia card, and then unmute the SPDIF switch the the m key.
Video and music should now work, but XBMC-menu-blips will still go through the analog ports. To fix that we need a shell as the xbmc user, and execute pacmd which allows us to talk to pulseaudio. Make sure XBMC is running and in the menu.
First, find the sink you want it to output on with list-sinks, memorize the index. (use shift+pageup/down to see more on a normal terminal).
then type:
set-default-sink the_index_you_just_found
Next, we need to force XBMC on that sink too (as else it’ll save which one it was on before). Find it’s index by doing list-sink-inputs, and then type:
move-sink-input xbmc_id sink_id
And the blips should work now. At first with some delay, but that will go away after playing music or video (XBMC just needs to reopen pulse). You can type exit to exit the pulseaudio command shell.
Next up is allowing XBMC to shut down or put the computer to sleep, I used this guide.
apt-get install upower acpi-support
Then open /var/lib/polkut-1/localauthority/50-local.d/custom-actions.pkla and add the following lines:
[Actions for xbmc user]
Identity=unix-user:xbmc
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*
ResultAny=yes
ResultInactive=no
ResultActive=yes
While we’re at it, also install the following packages to allow USB auto-mount:
apt-get install udisks usbmount ntfs-3g
And open /etc/usbmount/usbmount.conf to add ntfs to the allowed filesystems, simply add it at the start of the FILESYSTEMS=”…” list.
Now to speed up booting a bit, I edited /etc/default/grub and set GRUB_TIMEOUT to 0, after which I ran
update-grub
At this point the XBMC is pretty much ready. All that’s left to do is set up the network access for smartphone remote control, and add all movie sources.
If any new developments are added, I’ll post a new item on this blog 🙂
At Iminent someone did something horrible:
The trunk pretty much contained:
And someone ,on presumably a mac or a *nix machine, added the directory “b\c”. In *nix, where the SVN server was run, this was a perfectly valid directory name. On Windows, what most of us run on, the backslash is a directory seperator.
So when TortoiseSVN tries update or check-out, it fails to create a directory like that. Even worse, when you try to delete the offending directory from the “Browse Repository”, it actually interpreted the \ as a directory seperator, so while you wanted to delete directory “b\c”, it ended up deleting directory c in b. My boss had fixed this by completely removing the trunk, and putting in a new one from his working copy, but this way you lose all history of the files, and any changes that he had made to the working set were not visible anywhere.
I fixed it by doing the following:
Tada: You now have a new trunk, without the offending changes, but with full history on all files, and you can safely issue a checkout, or an update on an earlier working copy 🙂
I am aware it’s probably possible to cleanly revert those changes from a *nix box, but we didn’t have any available at the moment, so I had to do it this way.
When compiling Google V8 on Windows, do not use an AMD64 version of Python.
Firstly, the scons installer will not function, as it can’t find a python version in the registry.
Secondly, even if you just install scons manually, the V8 SConstruct file will fail. Because the return value from platform.machine() is now AMD64, the GuessArchitecture function in V8’s build script will not recognize a valid architecture, and the entire thing will fail.
If you just uninstall Python, and re-install an x86 version, everything will function fine.