Technology

Making The Mele F10 Usable In XBMC (Linux)

Ever since acquiring the Mele F10 3-in-1 remote control, many users wished they could get it to work properly in. XBMC. The F10 was a first generation product with three modes which had been succeeded by the F10 Pro 5-in-1 remote control which has (obviously) a total of five modes.

These modes are:

  • IR Remote Control
  • Air Mouse
  • Keyboard
  • Microphone
  • Speaker/Earphone jack

As with many first generation products, there are issues, bugs, and oversights that the user must contend with in order to get the most of them. By far the largest issue with the original F10 was that, by default, only 14 of the 21 buttons on the remote side of the device were accessible as keyboard keys. The Power button was scrictly for sending a power on/off signal via IR. The Mouse Startup button was only for activating or deactivating the air mouse mode. The Back button was a right mouse button. The button in the centre of the circular pad was a left mouse button. The Menu button was a middle mouse button. The Subtitle and Audio buttons were not accessible. Furthermore, anytime one of the mouse buttons were pressed, the Mele F10 would immediately enter air mouse mode. This was a major issue when using XBMC.

Like with other remotes, there are three solutions were created by the community to correct their quirks. They are in order of lowest to highest effectiveness:

  1. Mapping accessible buttons via XBMC’s XML keymaps
  2. Mapping accessible buttons via getscancodes and udev
  3. Mapping accessible buttons via hid_mapper

The last solution is the one that will be explained as it is the only one that captured every single button on the Mele F10 aside from the Power button and the Mouse Startup button. This is under the assumption that you have already installed hid_mapper from here: https://github.com/Claudio-Sjo/HID_linux_xbmc_driver and that you have a terminal and text editor open.

Note: hid_mapper was originally created by coldsource who posted source tarballs in this thread in the XBMC forums. The code was then updated by forteresce who then put it up on github. Claudio-Sjo then forked that code, updated it, and put it in a new repository.

Plug in the dongle for your remote and execute this command:

cat /proc/bus/input/devices

Which will show you the vendor (manufacturer) and product IDs that you’ll need for the rest of the steps. You are specifically looking for this line here:

I: Bus=0003 Vendor=1915 Product=af11 Version=0111

Which will show up in the last block of lines that are shown in you terminal As you can see, the manufacturer ID is 1915 and the product ID is af11 respectively. Now run this command as root:

hid_mapper --learn --lookup-id --manufacturer '1915' --product 'af11' > mele-f10.map

and press each key that you need to map. Be sure to keep track of which keys you pressed as the key codes don’t give you much indication of what key was pressed. You will see the ID of each key in the terminal when hid_mapper reads each key when you press them but they don’t usually get piped into the file. Make sure that if you wish to use the all of the keys in the keyboard on the back, to record those as well!. Provided that you did everything correctly, you should end up with something that looks like this:

Looking for Manufacturer : 1915
Looking for Product : af11
Found HID device at /dev/hidraw2
--- Vendor = 2.4G Wireless Receiver
--- manufacturer = 1915, device = af11
Found HID device at /dev/hidraw3
--- Vendor = 2.4G Wireless Receiver
--- manufacturer = 1915, device = af11
Found HID device at /dev/hidraw4
--- Vendor = 2.4G Wireless Receiver
--- manufacturer = 1915, device = af11
Found HID device
Opened HID interface on /dev/hidraw2
Opened HID interface on /dev/hidraw3
Opened HID interface on /dev/hidraw4
00 00 1e 00 00 00 00 00
00 00 00 00 00 00 00 00

Where a line made up of numbers higher than zero with or without accompaning letters is a keypress and a line made up completely of letters is a key release. After cleaning up the file (aside from removing that honking wall of text above the key codes) and adding key definitions from /usr/include/linux/input.h you should end up with something that looks like this:

00001e0000000000:KEY_1

As there is no other formatting requirements for the file, you can add comments and blanks like I did here:

# Front
# Top pair
0000280000000000:KEY_ENTER
01020000000000:KEY_ESC

# Circle pad
01010000000000:KEY_ENTER
0000520000000000:KEY_UP
0000510000000000:KEY_DOWN
0000500000000000:KEY_LEFT
00004f0000000000:KEY_RIGHT
...etc

I’ve modelled my keymap file after the global keyboard controls for XBMC which you can find at /usr/share/xbmc/system/keymaps/keyboard.xml. As long as the each line that contains a key code and key description is valid, hid_mapper can map the keys of the remote. To check the file you finished, run this command as root:

hid_mapper --manufacturer '1915' --product 'af11' --map 'mele-f10.map'

and press a few buttons. If everything works, great! If not, start debugging the file.

After doing all of that, a few more steps must be taken. To prevent the Mele F10 from being picked up by X11 and having its buttons mapped, insert this text into /etc/X11/xorg.d/50-HID-Blacklist.conf and save it:

Section "InputClass"
         Identifier "Remote blacklist"
         MatchUSBID "1915:af11"
         Option "Ignore" "on"

EndSection

Next, to have the Mele F10 buttons mapped when your HTPC boots insert this text into an executeable script:

hid_mapper --disable-repetition --manufacturer '1915' --product 'af11' --map '/hom/xbmc/mele-f10.map'

and have that script called by the system management daemon for your Linux distro (systemd for Arch Linux, Debian, etc., OpenRC for Gentoo, UpStart for Ubuntu).

Many thanks go to seo from the OpenElec forums for finding this out and presenting it in this thread:
http://openelec.tv/forum/104-bluetooth-remotes/66542-help-configuring-keyboard-mapping-starting-3-1-6?start=15

Creating USB Install Media For A Mac Under Linux/BSD

Isn’t as hard as one might expect. I expected that since I was working with a Mac, that the boot media required a special and complex partition setup. Only the former is true.

In order to create the USB install media, you’ll need five items:

  • An 8 GB or larger USB 2.0 or USB 3.0 flash drive
  • A DMG file (disc image) for the release of OS X that you want or need
  • A computer running a Linux or BSD operating system
  • dmg2img[1]
  • pv[2]
  • GPT fdisk[3]
  • dosfstools[4]

I will assume that you already have some knowledge of the commandline for the OS that you are using.

Creating the install media is a relatively simple and straight forward process. As the DMG is a disc image containing multiple partitions, we need to extract and convert the correct one as it holds the installer and associated software. Look for the number of the partition with the Mac_OS_X or OS_X label by running:
dmg2img -l (OS X filename).dmg
And extract the that partition with:
dmg2img (OS X filename).dmg -p (partition number) -o (OS X filename).img
Plug the USB flash drive into your computer and wipe the MBR:
sudo dd if=/dev/zero of=/dev/sdX bs=1024 count=1
And create the partition table using either cgdisk or gdisk (both from GPT fdisk). Two partitions are needed for this to work[5]. You will need the first partition to be the EFI System partition since the drive is larger than 2 GB. This partition is 200 MB in size and has type code EF00. The second partition is the main partition where the installer and associated software that was extracted earlier will be stored. This partition may take up the rest of the space and has type code AF00. Write the partition table to disc when you’re finished. Unplug the drive from the computer and plug it back in to have the new partition table that you wrote to disc be read. Now comes the last two steps.

The EFI System needs to be formatted with a FAT32 filesystem which can be accomplished using:
sudo mkdosfs -F 32 -n EFI /dev/sdX1
The IMG file containing the installer and associated software can now be written to the last partition using:
pv (OS X filename).img | sudo dd of=/dev/sdX2 bs=4096
This will ensure that you have an ETA when copying the data so that you can take a small break.

And that’s all there is to it! Once the copying to the second partition is complete (i.e.: no light flashing on the flash drive), unplug the drive from your computer and plug it into the Mac. Immediately after Powering on the Mac, hold down the Alt or Option key (depending on your keyboard) until a menu screen shows up where you can select ‘Mac OS X Install DVD’. If that menu doesn’t show, you’ll either boot from the flash drive (as the internal hardware has no bootable partitions) or something else is wrong (and you’ll have to troubleshoot it). Either way, congratulations on making it this far and I hope you’ll continue to enjoy your Mac.

References:
1: http://www.vu1tur.eu.org/tools/
2: http://www.ivarch.com/programs/pv.shtml
3: http://www.rodsbooks.com/gdisk/
4: http://daniel-baumann.ch/software/dosfstools/
5: https://developer.apple.com/library/mac/technotes/tn2166/_index.html

Embedded Audio Sources

Introduction / Hardware Part 1

Just how many things can the Raspberry Pi become? I’m currently working using the one I have as a VPN concentrator thanks to Arch Linux ARM and SoftEther. Other people have used it for much more than that. As I sat by my -turbofan engine- workstation computer listening to music while coding, I thought, “Time for some peace and quiet.”. The biggest problem is that my -turbofan engine- workstation computer is the only system with a complete version of my entire music collection. Remedying that issue would prove to be fun.

Software

I first started looking at software. While I know how to install and configure Arch Linux ARM, ALSA, and MPD, there are other projects specially tailored to what I needed. RaspyFi was the first one that I found. The team that was working on it split and created two different projects: Volumio and Rune Audio. The original founder of RaspyFi created Volumio using the same architecture as RaspyFi (Debian based) with extra customisations. The creators of RaspyFi’s web UI created Rune Audio with Arch Linux (<3), custom compiled versions of Nginx and PHP-FPM, and a reworked variant of the RaspyFi web UI code. Voyage MuBox is another Debian based OS but with better support for another low-power, high-performance system: the CuBox-i.

Hardware Part 2

The CuBox-i is an interesting little system from SolidRun. For just over the price of a Raspberry Pi, the CuBox-i1 includes two USB ports, a full 10/100 ethernet port, an infrared receiver, and a S/PDIF (toslink) port. It also has a FreeScale i.MX6 Solo running the show at 1 GHz and 512 MB of RAM. All of these components are contained in a cube measuring 2 inches per side. The one thing that it lacks that the Raspberry Pi and some other hardware have is support for DACs via I2S. This would cut down on the number of devices needed in the chain.

There is also another device whose name starts with cub: the CubieBoard. For around the same cost as a CuBox-i1, the CubieBoard 2 includes two USB ports, one SATA port, a full 10/100 ethernet port, one Micro SD card slot, an infrared receiver, and 4 GB of NAND flash. It also has a dual core ARM Cortex A7 running the show at 1 GHz and 1 GB of RAM. All of this placed on a single board that is not much larger than a Raspberry Pi.

Having infrared receivers on these machines (the Raspberry Pi needs an add on) make either of them perfect for a music player that can be controlled via the network or using an infrared remote. This is great as I still have my original Apple remote from my MacBook.

Software Part 2

Infrared control of MPD requires two things: LIRC and MPC. LIRC acts upon signals from the infrared receiver of the machine. MPC is a commandline MPD client. The two together would allow for quick, conveinent control over music playback after setting up MPD and creating the playlists. It almost negates the need for the web UIs that Rune Audio and Volumio have. Almost. The web UI of each project also allow for changing various system settings such as enabling I2S on the Raspberry Pi. Very useful.

Hardware Part 3

Now that the source hardware and the software to run on it have been sorted out, what about the rest of the audio chain? A DAC and an amplifier are required to get the best sound quality out of my headphones. After much research, only two DAC+amplifier stacks make the shortlist: 1) Schiit Modi and Magni 2) NwAvGuy’s ODAC and Objective 2 (assembled by JDS Labs). The latter is said to be more transparent while the former should offer more power for my headphones.

As was mentioned in ‘Software Part 2’, the Raspberry Pi has support for DACs that can be connected via I2S. The DACs are connected to the two rows of four header pins (which you install yourself) on the Raspberry Pi. These include the Hifiberry DAC and the IQaudIO DAC. Either of these paired with either the Schiit Magni or Objective 2 will mmake a great match.

Hardware Part 4

This is the really simple part. Either the music is stored on directly attached storage or network attached storage. I could use a harddrive or USB flash drive to store the music on if I go the directly attached storage route. If I go the network attached storage route, I’ll build my own NAS.

Audio Chains

Knowing how the music gets from the machine to your headphones is important. Yes, headphones as I have no space to implement even a near-field speaker setup.

With the Raspberry Pi, it would be setup like this:
Storage -> Music -> MPD -> Raspberry Pi -> Hifiberry DAC or IQaudIO DAC -> Objective 2 or Schiit Magni -> Headphones

With the CuBox-i1 and Cubieboard 2, it would look like this:
Storage -> Music -> MPD -> CuBox-i1 or Cubieboard 2 -> ODAC or Schiit Modi -> Objective 2 or Schiit Magni -> Headphones.

Conclusion

With some money and know-how, you can definitely build an embedded audio player that will be small, efficient, convenient, and most of, quiet. There’s no need to invest in expensive computers or cables just for the sake of playing music with the highest sound quality whilst remaining silent. The Raspberry Pi, Cubox-i1, and Cubieboard 2 are proof of that.

Playing Around With BIS On A Tablet Plan

Ever since I acquired my BlackBerry Bold 9900 last Wednesday, I’ve tried to find a solution to push email for it. My previous solution, MyFunambol is now One Media Hub and dropped push email support while retaining the rest of its synchronization abilities (and even adding a few more). The plan that I’m on doesn’t change for another week and a half. Until then, I needed to see if BIS would work regardless of the plan that I had.

After trying several times to register the 9900 on the network, I realized that my idea would not work. I will have to wait for now.