Touché 0.3 Released!

Another couple of weeks, another major release!
This time with more interesting features I hope.
First of all, now Touché is a KDE only application, no more dual releases with Qt-only version. Of course, this may disappoint someone, but this allowed me to add some nice new features, like Global Shortcuts for profile switching.
And profiles themself were improved too, both fixing small problems, and adding a “Default” profile, when no other profile is available.
Default profile will also provide a “fallback action” if some key is not configured on the selected profile, this way you can enable an action on multiple profiles without having to copy it.

Main menu was refactored a bit, It’s nicer and much more well organized.

Code was refactored as well, which lead us to an API for adding new “device modules”, not just HID devices.

And we have a living example too: Wiimote support. You can easly setup a Wiimote as remote control by just enabling it in the “Configure Touché” menu entry, “Modules section”, then by just connecting it. Currently it supports every physical button on the wiimote; I plan to add some other nice stuff too as gestures.

As usual, source tarball is available on github download page.
More downloads and information in Touché Homepage

How to install System Rescue CD + rEFInd in an USB Stick for EFI systems (Macboot, UEFI PC/Laptops)

update: with further reading of rEFInd website, I could find a better way to specify more options with only one menu entry. The configuration section was subsequently updated.

This blogpost comes in handy mostly if you have an EFI system (Apple Macbook, but also some Intel based desktops and laptops), and you need a portable USB stick for emergency booting.
I’ve been using System Rescue CD for a long time now, it’s probably one of the best  rescue tools around.
It’s a live Linux distribution that can help restoring not only Linux installations, but Windows and OSX too, has gparted as a partitioning tool, can restore bootloaders (such as grub), has network support and ssh server (so you can use rsync to copy filesystem, control it remotely, browse the web to search for help if you panic) but being a live linux distro it may be used in almost every way you like. You may give a look to their homepage to see details.
It can also be installed in an USB stick, which comes quite in handy as you don’t have to carry a relatively big support as a CDRom; nowadays usb sticks are cheap, small and fairly reliable, I always carry with me a SystemRescue usb stick for emergency repairs.

It might however be problematic using it if you have an EFI/UEFI based system, since SystemRescue CD doesn’t actively support it.
For instance, in a macbook you can boot a system rescue cd, but not from usb stick, as the EFI system can boot usb sticks only if they contains an EFI bootloader.
Which is just annoying if you have a macbook pro, but becomes a real problem if you have a Macbook Air, as they don’t have a CDROM Reader.

Another tool I’ve recently discovered is rEFInd Boot Manager, which is an EFI bootloader capable of discovering other EFI bootloaders. Beside being an excellent bootloader it can also be used as a rescue tool, since it might boot your system if your installed bootloader has been misconfigured.

Since rEFInd can directly boot Linux kernels too, if they’re compiled using EFISTUB option (version >= 3.4), and since System Rescue CD does itself contain a 3.4 kernel, can this help us, combining both of these tools in a single USB Stick?

Of course the answer is yes!

Let’s see how.

First, download System Rescue CD, and install it on the USB Stick using these  instructions.
Now download rEFInd too, just choose the CD-R Image File on their download page.
Extract rEFInd CD-R Image copying all the files into the USB Stick.
Open/EFI/boot/refind.conf and modify it as follows:

  • find the “scanfor” commented out line, and add this one (uncommented, of course):

    scanfor manual,internal,external,optical,hdbios,biosexternal,cd

  • At the end of the file, add the following lines (you may replace “it” with your favourite keymap):
menuentry "System Rescue CD x64" {
        icon /EFI/boot/icons/os_linux.icns
        loader /syslinux/altker64
        initrd /syslinux/initram.igz
        options "scandelay=5"
        submenuentry "IT Keyboard, cache" {
          add_options "setkmap=it docache add_efi_memmap"
        }
        submenuentry "IT Keyboard, cache, noapic" {
          add_options "setkmap=it docache noapic add_efi_memmap irqpoll acpi=force"
        }
        submenuentry "IT Keyboard, nocache" {
          add_options "setkmap=it"
        }
        submenuentry "IT Keyboard, nocache, noapic" {
          add_options "setkmap=it noapic add_efi_memmap irqpoll acpi=force"
        }
        submenuentry "No EFI" {
          add_options "noefi"
        }
        submenuentry "VGA" {
          add_options "vga=791"
        }
}
And… that’s it! We’re done! Just try it out, rEFInd will show you the three System Rescue CD options, and the other installed operating systems.
You may of course customize kernel boot arguments with the options supported by System Recue CD.
As an optional step, since EFI is supported manily on x64 machines (that’s why I’ve only added x64 kernel boot options) you may safetly remove the various “*ia32*” files you may see around, which should be “shellia32.efi”, “refind/drivers_ia32″, “refind/refind_ia32.efi”, “EFI/boot/drivers_ia32″, “EFI/boot/bootia32.efi”.
Note: if you have one of the awful new Macbook pro/retina/air, which have serious problems booting linux, you may want to add the options “add_efi_memmap noapic” to properly boot System Rescue CD with EFI. I have already included it in one of the submenus.

Touché 0.2

Hello folks? Back from vacation?
I am, and so is Touché, with a second major release!

The most important change in this version is the addition of profiles, meaning you can have multiple bindings configured for each device, and you can switch them by context menu.
This release also features many code reworks, GUI and backend fixes and refactorings opening the way to future new features.

Here’s the full changelog:

  • Ported build system to CMake
  • Added profiles, to have different bindings for the same keys
  • Major code cleanup, allowing to add more engines (next one probably will be Wiimote)
  • Cleaning up desktop file and appName (fixing some issues with encoding)
  • Binding keypress and keyrelease events on “Translate to key” dialog
  • Added “aliases” in keyboard database, so now different device version can be mapped to the same key (example: apple remote)
Now the bad news: both the keyboard database file and the configuration file have changed.
The first one won’t bother you, unless you’ve defined a custom keyboard mapping file. In this case, please contact me, I can help you fixing it, and it can also be added to the default keyboard database file.
For the configuration, it’s much easy to migrate it:
  • cd $HOME/.config/GuLinux
  • mv Touché.conf Touche.conf # I renamed it, to avoid encoding issues
  • now open Touche.conf with your favourite text editor, and replace “[bindings]” with “[bindings_Default]” (or bindings_YourDesiredProfileName).

That’s it!

Just enjoy the new release, and don’t be shy! Feedback is welcome!
More downloads and information in Touché Homepage

21:27 (GMT+2) Update: there was a small issue with the configuration GUI. I modified source code to fix the problem. Please download again and rebuild the package if you have any inconvenience.

Wiimote Stellarium Plugin

As i wrote some days ago, I planned on doing some hack so control KStars with a Wiimote.
It turned out KStars isn’t the right target, as it seems to have no plug-in support (and I don’t want to modify core yet, as i’m still in an experimental phase).
But reading data from wiimote and correctly interpreting was already done some days ago, thought it was a little bit hard, so I switched to Stellarium instead.
This is the result: http://www.youtube.com/watch?v=BhVHJJaQ8Gs

Of course it’s just experimental code, it’s barely usable.. but it’s a start.
Source is here: https://github.com/rockman81/StellariumWiimotePlugin

Now some technical stuff:
The Wiimote gyro sensors aren’t easy to read, as they don’t send you current angle, but only
It doesn’t report current angle, instead it does report angular speed.
But afterall you can deduce current angle just dividing speed by elapsed time between each message report.
I had to do some tries before finding the proper way of “moving view window” on Stellarium.
It’s not so well documented, and i’m not exactly happy about current solution, but it works, and i’ll ask some help in their mailing list soon.
This solution anyway is easier than i thought, as it only receives as input angles delta, meaning it’s also easy to “align” your telescope to stellarium (just point an object with telescope, then manually point stellarium to that object).
What’s missing:

  • better calibration (angles “seem” correct, but i’m not entirely sure…)
  • better movement translation (i’m ignoring one axis, they should be all taken into account, and compensate misalignment).
  • Maybe some alternative way of displaying wiimote data in stellarium, such as a “virtual” object in sky. this way you can see how close is your telescope to a desired object.
  • Equatorial mount support (currently if there is an axis rotation it’s not detected and properly corrected, and it’s interpreted the wrong way).
  • ….many other stuff, but it’s too early to get a detailed list :P

Hello planet! (again)

Just a quick update: after some years of inactivity, i’ve decided to go back into KDE hacking.
These years have been quite good, moving in Milan, working in a great agile team full of people i really love working with, but i really missed KDE community, open source, and c++ hacking.

So i’m taking advantage of my nearly one month vacation as a kickstart, hoping to be able to keep enough free time for KDE after being back to work.

What will i do in KDE? Well, i have no precise plan.. But i already started by adding Chrome/Chromium support to KRunner (probably it’ll be out for KDE 4.10, proposed branch here, i’ll blog more about it probably, as for me it’s a nice example about unit testing and refactoring) and fixing some bugs (i just proposed a patch for Konsole).

It also wouldn’t be bad to keep working on Touché, maybe integrating it more with KDE. For instance, it could merge with KHotKeys, which is kinda buggy too at the moment.

Also, I plan to hack on my Wiimote (with motion plus), it would be great to be able using it as a pointer device for KStars (exactly the way Skeye is doing for android devices, “Virtual DSC”, or “PushTo”).

So, stay tuned!

Macbook pro 2012 (8.1) e Ubuntu

Apple: un passo avanti, 10 indietro (come al solito).
All’arrivo dei nuovi macbook aziendali (perchè usare un mac in azienda, poi?) mi sono meravigliato di un notevole miglioramento del sistema operativo più antipatico e chiuso del mondo: una volta ripartizionare la partizione di sistema di OSX era veramente complicato. Oggi invece è possibile farlo anche dallo stesso sistema operativo: innovazione non da poco, credo che su linux si possa fare solo con btrfs.

Ma veniamo alle rogne: provo la “solita” procedura di installazione, usando Refit perchè ok, grub “dovrebbe” supportare il boot efi nativo, ma si sa, io non mi fido mai molto…

Occhio a selezionare il “partizionamento manuale”.
Come layout del disco scelgo il seguente:

  • sda1: partizione EFI di osx (già esistente).
  • sda2: partizione di sistema osx (già esistente).
  • sda3: partizione di recovery di osx (già esistente).
  • sda4: swap linux, dimensioni pari alla ram del sistema (nel mio caso, 4GB)
  • sda5: partizione root linux (non mi andava di creare mille partizioni, ed ho messo tutto sulla root, potrò sempre cambiare in seguito).

Accorgimento importante: in una delle schermate di installazione viene chiesto dove installare il boot loader (grub2). Io ho scelto la partizione root linux (quindi /dev/sda5), e a parte le rogne di OSX che descriverò in seguito la cosa è andata liscia. Un’alternativa (da testare) potrebbe essere sda1.

Il primo boot è andato senza problemi. Una cosa che però mi ha stranizzato quasi subito è stata la scomparsa di refit.
Dopo un paio di riavvii decido di riavviare osx per verificare il funzionamento di alcune periferiche. E qui iniziano i problemi.
Anzitutto, grub2 non riesce ad avviare osx. Probabile qualche incompatibilità con lion.
Cercando su google la soluzione migliore sembra essere di avviare il mac tenendo premuto il tasto “option” (che è evidentemente il modo fighetto dei mac-isti di chiamare il tasto “ALT”).

Ok, osx si avvia… problema: ha sovrascritto senza pietà grub, infatti al riavvio successivo è impossibile avviare ubuntu.
Ri-ok, pazienza, proviamo a installare refit: risultato, refit NON viene mostrato (mi sa che viene sovrascritto anche lui) e in più non si avvia più neanche osx.
Ri-ri-ok: una soluzione che riesco a trovare è di installare refit su un cdrom. Questo riesce a far avviare sia osx sia linux.
Ma ovviamente bisogna metterci una pezza.
Ecco come sono riuscito a rimediare:

Al primissimo avvio di Ubuntu, in /etc/grub.d/ creare un nuovo file per inserire una entry “custom” in grado di avviare OSX.
Nel mio caso, /etc/grub.d/42_osx_chainloader
Ricordarsi di marcarlo come eseguibile (chmod a+x /etc/grub.d/42_osx_chainloader).
Il contenuto è il seguente:

#!/bin/sh
cat <<EOF
# Chainloading OSX EFI Bootloader
menuentry "OSX-Chainloader" {
        insmod part_gpt
        insmod hfsplus
        set root='(hd0,gpt2)'
        search --no-floppy --fs-uuid --set=root 39e12735-fb69-4c59-9f5e-ac9a8642e509
        load_video
        set do_resume=0
        chainloader /usr/standalone/i386/boot.efi
}
EOF

Ovviamente se OSX non fosse su /dev/sda2 bisogna modificare inserendo il dispositivo giusto (ma su una installazione di default dovrebbe andar bene).

Eseguire “sudo update-grub”
Al prossimo boot, troverete la nuova entry “OSX-Chainloader”. Sceglierla per avviare osx.
Adesso il problema è evitare di far sovrascrivere grub da osx.
Io ho risolto scrivendo un file che reimposta grub come bootloader di default.
Posizione: /usr/sbin/bless_grub.sh

 /dev/disk0s1 /Volumes/efi

bless --folder=/Volumes/efi --file=/Volumes/efi/EFI/ubuntu/grubx64.efi --setBoot
bless --mount=/Volumes/efi --file=/Volumes/efi/EFI/ubuntu/grubx64.efi --setBoot

Anche questo file deve essere marcato come eseguibile (chmod a+x /usr/sbin/bless_grub.sh ).
Ora bisogna fare in modo di far eseguire questo file ad osx come root ad ogni avvio.
La soluzione “pulita” è usare plist, l’init di apple. Essendo abbastanza complesso da usare, ho optato per la soluzione “quick&dirty”, ovvero aggiungere la riga

 /usr/sbin/bless_grub.sh

Alla fine del file /etc/rc.common.
Abbiamo finito: adesso grub2 è in grado di avviare osx, ed osx ad ogni avvio reimposta grub2 come bootloader predefinito.
Unico problema ancora aperto: nel mio caso grub2 ci mette ben 20 secondi ad avviarsi.
Idee?
Update: aggiornando a Ubuntu 12.10 beta (e quindi presumibilmente anche grub) il problema sembra sparito…
Update-bis: ho notato che a risolvere non è stato l’aggiornamento, infatti il problema si è ripresentato.   Pensandoci meglio però ho trovato la soluzione effettiva: rieseguire “grub-install”, senza parametri.

Touché 0.1.1

New minor release available for Touché, mostly for build and bug fixes.
Here’s the changelog:

  • Make build more reliable.
  • Desktop file fixed for kdeinit launch error.
  • Use of kuniqueapplication in release mode (no need for multiple instances).
  • Fix crash when removing a device with configuration dialog open.
  • Microsoft Wireless Keyboard 3000: added “F-Block” key mapping.

Source tarball: http://github.com/rockman81/Touche/downloads
Arch Linux packages (AUR):

Ubuntu packages:

Touché 0.1 Release!

After a week or so of both developing and testing, I am finally able to present a fully featured 0.1 release!
A lot of work has been done, comparing to the first “proof of concept” version.
Most notably, a configuration user interface!
Here’s the full changelog:

  • Catch input event from /dev/usb/hiddevX, otherwise ignored by the system.
  • Json Devices Database: pretty easy syntax for adding new devices. Both Qt (simpler) and KDE (stilish) main applications are supported.
  • Fully configurable by a simple user interface.
  • Provides an udev rule to easly fix permissions on your usb devices.
  • Automatically configures xmodmap to bind your unrecognized keys.
  • Full support for Microsoft Wireless Keyboard 3000 (a.k.a. Microsoft Wireless Destkop 3000); possibly similar variants too.
  •  Support for Apple IR remotes (old MacBook pro tested); there are different variants, two of them are configured right now.

Source tarball available here: http://github.com/rockman81/Touche/downloads

Arch linux packages (AUR):
Touché in action

Touché: special key recognizer for Linux Desktops

a.k.a. Make your extra keyboard keys “just work”.

read me first: apparently planet kde linked only this post from backlog instead of newer ones.
You can see more updates about Touché (including first two “stable” releases) here:
http://blog.gulinux.net/touche/

I always loved having some spare extra keys in my input devices.

Contrary to Apple’s philosophy, which every year tries to remove some keyboard or mouse button here and there, just because “user might be scared! too much stuff to handle!”, i find quite more simple to just press the “Play” button on my keyboard to start my audio player, or “Next” to skip to the following song, or “ZoomIn” to enlarge browser fonts, and so on.

It’s also quite more productive, in my point of view: for instance i use a lot virtual desktops, therefore i can “switch context” just by switching desktop (for instance, desktop 1: internet; desktop 2: console apps; desktop 3: instant messaging; desktop 4: application development). And what’s faster? Typing “CTRL+Shift+F2″ (if you can remember it!) to switch to desktop 2, or just having a mouse with an extra button, binded to the (in my opinion, beautiful) desktop grid effect?
One button click, and you’re directly here:

I can even remember that when i used to play Quake 3 Arena, my mouse with two extra lateral buttons gave me a fair advantage on my enemies, allowing me to fast-switch to the “most useful” weapons.

Therefore, as you might imagine, i always try to buy keyboards (and mices) with lots of extra keys. But as some of you might have experienced, not all of them do work.

My last purchase is a Microsoft Wireless Keyboard 3000: not so bad, it has lots of extra keys, the bundled mouse has 4 extra buttons (other than the standard 3 ones and the wheel), and most of the extra keys do work out of the box.

But “most of them” is not enough.

I never could get to work the “Flip Window” key  (bottom-right), nor the “12345*” keys, next to the standard multimedia keys. I barely could have the “ZoomIn-ZoomOut” keys (left), because i noticed that they were captured as joypad events (joypad? Wtf?)

So, after some research i noticed that all these keys do generate an event, in the special device “hiddev0″.
And i wrote an application to read them: Touché.

It’s still in heavy development, it lacks a configuration utility, and currently it supports only my keyboard model, but it’s probably easly configurable to support other keyboards, if they do generate events in hiddev too.
And beside what’s missing, it’s already fully functional: it can both translate your special key to a Xorg recognized key, or run a custom command.

If you want your keyboard supported, you can inspect the application output (with the command line argument “–dump-events”), and contact me to get support.

Build instruction included in the README file.
Feedback is welcome :)

Test Driven Development, C++ e Qt: Integration Tests

Nella precedente puntata abbiamo imparato a testare unitariamente oggetti complessi che necessitano di risorse esterne, come ad esempio la rete.
Questo ci da un certo livello di confidenza, ad esempio nell’implementazione della parte più “algoritmica”, ma è ovvio che prima o poi bisognerà provare le cose sul campo.
A questo servono i test di integrazione.

Nel nostro caso, un download manager, in cosa consiste un test di integrazione?
Dipende anche da qual’è lo scope che vogliamo testare. Ad esempio, potremmo voler analizzare solo un aspetto (per esempio, solo la comunicazione con un server vero via http) oppure scrivere un test “end to end”, che verifichi, sia pure in maniera meno precisa, il giro completo.

Un test “end to end”, nel nostro caso, potrebbe essere incentrato su DownloadQueue: gli passiamo le dipendenze reali, avviamo un webserver locale, passiamo come url da scaricare un file temporaneo, e verifichiamo che il file sia effettivamente stato scaricato.

Ci accorgiamo però che per fare questo ci manca ancora un pezzo: un oggetto che, data una NetworkReply, scriva su filesystem i bytes scaricati.

Creiamo quindi la sua interfaccia, ad esempio NetworkReply, che avrà più o meno questa forma:

class WriteDownload : public QObject {
    Q_OBJECT
public:
    WriteDownload(QObject *parent) : QObject(parent) {};
    void write(NetworkReply *networkReply);
};

Adesso possiamo scriverne una implementazione che scrive su filesystem, testandola in integrazione usando però un NetworkReply finto.

python -m SimpleHTTPServer
random bytes
assert su dimensione

Verifica salvataggio su filesystem
nome del file: come recuperarlo? nota: QNetworkReply->request()->url()