DIY Handheld console – version 2

Although it was great to work on SuperGamePi-based DIY handheld console project, the device wasn’t that much fun to actually use and play. I wasn’t really thinking about it when I was building it – I assumed that fun from constructing & hacking around would be rewarding enough – yet I got nervous more than once when I actually tried to play longer than for a few minutes and there was always some inconvenience.

What went wrong?

Problem 1 was that my soldering work wasn’t perfect and I was having connection shortages which caused gamepad buttons not working or – actually worse – working when they shouldn’t. With a few iterations of desoldering and resoldering, I’ve managed to actually fix that issue.

Problem 2 was that after so many deconstructions and reconstructions of GamePi as project needed, screw holders eventually gave up. I’ve used super glue to fix them and it worked for a while, but not long enough. Still, that could be fixed, in worst scenario by reprinting GamePi case (which was a bit pricey).

Problem 3 was the one which eventually led me to go back to drawing board and redo the whole Pi-based handheld console project. Even though buttons worked, they haven’t really worked well. They were incosistent in tactile feeling plus amount of force needed to press each button differed. This wouldn’t be a problem in many projects – some house applications or soundboxes and such – but in gaming? It’s instant death because of jump which didn’t happen, loss of trial in Mario Kart, shooting failure in worst moment, even in turn-based jRPGs it was very irritating.

Handheld v2 – design!

I decided to completely change aproach and build modular system which would allow to swap components easily and to use already working gamepad part. Of course, it’s still possible to use  many other options: one can print 3D case which enables to hold SNES-like controller whole, gut Wii U “tablet” and insert Pi there or use smartphone bluetooth gamepad-case.

I’ve decided to go with last option, as BT gamepads are generally nicely recognized by Raspberry Pi/Retropie and their construction should enable flexibility in rebuilding later on. I didn’t like any option provided by popular company iPega, but found very promising photos & spec of joypad FlyDigiWee. It seemed rather unknown/untested in non-China world, yet I’ve liked it so much that I figured it’s worth trying out. Eventually I’ve had to order it twice and waited almost half a year for it (yeah…), but bad luck stopped there.

Building parts

In first version of handheld, I’ve used cheap 5″ GPS navigation screen plus not so cheap controller driver by Adafruit. Initially I wanted to use that for v2 as well, but unfortunately plastic holder for controller tape broke and I couldn’t find anywhere reasonably priced replacement. While thinking about about 3D printed replacement part, I eventually ordered another cheap 5″ screen with HDMI, designed for Raspberry Pi as it was accessible in my country.

There was an iussue with placement of GPIO block used for touch which I didn’t need and microUSB power port was put at right side of the screen – it collided with gamepad holder – so I removed both of them using as low force as I could and with help of my friend Ingvar I soldered 5V power plus ground instead.

Those changes made it really easy to use Raspberry Pi’s two GPIO ports to give power to the screen. Success!


Holding it together

While gamepad holder matched very well with screen (OK, after making stupid “backlight switch” smaller), I needed a way to hold RPi in place. Once more, first idea was to print 3D case for whole construction, but that would break modular approach so I decided that the simplest way is the best way – I ordered beautiful blue/clear case for RPi (with access to GPIO of course) and mounted it to gamepad with… cable holders. I can’t imagine more modular approach. ;)

Power over 9000!

While screen was nicely powered by RPi GPIO ports, Pi itself needed power. I’ve done another quick research and eventually reused Powerbank which I bought for v1. It has 6000 mAH capacity which is enough for a few hours of work (haven’t measured it exactly so it’s approximation) and 2.1A USB exit which is optimum for RPi 2 B. Potentially it could be not enough for RPI 3, but I use Pi I have (duh) and Pi 3, although has more power, has also higher needs – not only powerwise, but also regarding cooling necessarry for proper running.

Going back to powerbank – it’s quite heavy for such a small project (160g), yet comparing to other ones (eg. aluminium Xiaomi one which I use with smartphone & tablet) I can’t find better option which would still have nice capacity and amper outage. Also, it’s about the same size as RPi in case which is great, because if it was any longer it would be not comfortable to hold console in palms (which kinda is a goal here).

As you may imagine, I’ve used cable holders to put it all together. Glorious! :)


HDMI powered screen and longer (comparing to standard usecase) space between screen and RPi caused that I couldn’t use compact HDMI connector to hold it together. In result I have to to use standard HDMI cable. Well, perhaps not standard, because I’ve used as short one as I could’ve find – but it was still not perfect. Then my friend Dźwiedziu came with suggestion to… make it tangled like an old stationary phone cord. Perhaps it was crazy, but worked! When you can’t hide it, make it intentionally visible. Cool!


This hasn’t changed from version 1 – I still use RetroPie and it’s a great piece of work. It’s configured to support a lot of emulators, custom ports and such. RetroArch is running in backend which enables automatic configuration and mapping, is easy to use and has great EmulationStation UI. Only competition for RetroPie is RecalBox – designed for ease of use whuch leads to having less configuration options available. And I always prefer to have as vast selection as possible.

SNES, GB&GBA, PSX emulation works great; N64 is so-so. All ports I’ve tested so far work great – DOOM, Duke Nukem 3D, Quake 1 & 3(!), Minecraft Pi Edition (but not with gamepad), Stratagus for WarCraft II (same), Cave Story and more. Please let’s not discuss emulation legality here. I can also turn in into full LXDE/Pixel desktop, but it’s more of gimmick than real usecase. After all this 5″ screen has only 800×400 resolution.

First version, which used custom-build switches connected to Arduino Pro Micro hacked around to work like keyboard, was great because it allowed to use gamepad in places where it isn’t available normally – eg. for DOSBOX games. I lost that functionality in handheld v2 unfortunately. While DOSBOX has nice mapper for assigning joysticks/gamepads buttons to keyboard keys, it’s not working properly with my FlyDigiWee – all buttons, except arrows, are reported as one. Too bad. I’ve tried to register gamepad as keyboard+mouse using Xboxdrv driver, but it hasn’t worked in DOSBOX and Stratagus as well. Maybe there will be something better in future.

What does the future hold?

Project is cool and I’m already using it a lot, but it’s a bit too heavy to my liking. It’s caused by powerbank which is the first thing I’d like to replace (maybe aside of “speakers”) – when they’ll create something lighter with more capacity and outage. Other than that, I’m satisfied. I may change Pi 2 to another module in the future, but probably not to Pi 3 – its power is not that great and its needs are much higher.

Let’s play!

Why do I use Linux?


It’s system which I can fully make look & behave like I want.

I prefer dark themes – no problem, tons of those to selects. My fonts, image settings, etc are shared system-wide for all the apps. Just like that, without questioning.

It has multiple desktop environments to chose, each offers different approaches on how system/UI behaves and settings to achieve even more crafted experience.

I chose Cinnamon, because it’s classic desktop paradigm, but with future in mind – adding more, not removing. I prefer dock to taskbar, so I’ve installed former, disabled latter, and it works great. I use workspaces heavily (even though I own 3 monitors) + software which keeps track of programs’ positions and set them just how I like ’em.


I can choose from many providers of core (or not) system functions. I can easily work with lot of different bootloaders, services, setting managers, and so on. I can choose from many kernel options, or even build one with own patches.

I do it for VFIO gaming machine, actually.

It’s beast for development

Python, C++, Ruby on Rails, PHP, Java or even C#. Everything feels natural in Linux workspace. Automated with scripts, I run whole development sets with one keypress (and then switch them off in same way).

Sure, I have some problems from time to time. I’ve had those on Windows too. Tracking & fixing on Linux is easier. I might not have them on macOS, but it’s too closed ecosystem for me to even bother.

Only on Linux I feel it’s my computer.

Quality of life upgrades

panoramaSome time passed, some hardware & software upgrades happened.

I’ve changed my host GPU to GeForce 660 as it’s still supported by official non-legacy drivers and support triple monitors without resorting to use Intel output. Even that it’s 100% possible to run, it’s much less hassle to just have it natively, out-of-box & with clean xorg.conf, not runtime script. :) Changed my CPU to i7-2600, upgraded RAM to 16 GiB. Still a bit short, lol.

Bought an SSD (Samsung 850 EVO) and it’s just great. Even if I still mostly sleep/resume my computer and Arch Linux host can’t be much quicker then it already was (because it’s fast and furious), Windows 7 gaming machine boots almost immediately and it’s great to quickly launch some game.

I’ve also managed to set up VFIO gaming machine (with W7 too) for my girlfriend.

Took some time to do cable management. Ah, so much cleaner.

And last, upgraded my workflow quite a bit – that’s planned for another post.


DIY: Raspberry Pi-based Retro Game Console

I got Raspberry Pi 2B for last Chrismas and decided I’d like to make a handheld. I didn’t have nearly any experiencence in making electronics, soldering, etc. before.


There are many similar projects like that in the web, so first I’ve decided to set my requirements (ease of use, RetroPie support, analog stick, and 5″ LCD screen) and found one great project at Adafruit… Which I later “disobeyed” many times – to support RPI2B (tutorial is made for RPI1) and mostly to use another parts – order from Adafruit store to Poland is unfortunatelly not reasonable in costs, so I’ve gathered my parts from stores in place… or Aliexpress. Mostly that.

I’ve decided to use same screen and screen controller board that Adafruit used (fortunatelly got both easily) to make sure it’s going to fit into 3D-printed enclosure (which was Adafruit one with bigger holes). It didn’t fit RPI2B easily, but good enough.

Biggest change was to not use SNES Controller board – I’ve changed it to external Arduino Pro Micro – which gave me built-in pull-up support and also was very nice to code.

I’ve used powerbank as battery.

Some cable soup, some broken analog-digital-converters (before I’ve switched to Arduino) and handheld gaming console is ready!

Triple monitor fun

I’ve finished another of my PC plans and upgraded to triple monitors. It was a big change for me – in the first few moments I wasn’t even sure if I’m going to get used to it, but soon I’ve started to love it. Much more (separated – and that’s good!) space for windows/terminals which I use a lot and a fantastic new way of more immersive gaming. It’s also much more appealing in terms of aesthetics. FYI I was using 2 24″ monitors before.

Obviously, my configuration couldn’t be standard, so let’s talk about quirks & tweaks.

I’m using 3 monitors with both Arch Linux host (GeForce 9800 GTX+) and Windows 7 gaming VM (GeForce GTX 960). To achieve comfortable change between those, I use HDMI switches placed under desk. Works great so far.

Monitors are mounted on a triple monitor stand. It was very difficult to find a good one. I was thinking about buying popular Ergotech one, but decided to try and buy less expensive (especially with shipping to Poland) and fairly new one from Duronic. I’m very happy with it in general, but it’s sturdy and hard to line up and level monitors perfectly, yet I’m almost there.

My 9800 GTX+ has only two outputs so to get all 3 screens working I need to use one output built-in onto motherboard GPU. Nvidia does all the rendering, Intel’s output is used only as transport route. I’ve needed to switch to Nouveau as it doesn’t work for me at all on Nvidia binary driver.

Script to turn on 3 monitors:

xrandr --setprovideroutputsource 1 0
xrandr --auto
xrandr --output HDMI3 --right-of DVI-I-1
xrandr --output DVI-I-2 --left-of DVI-I-1

I also utilize 3 monitors on Gaming VM – it’s working very well after enabling Surround in Nvidia GPU options. So far I’ve tested Witcher 3, Fallout New Vegas, Torchlight etc. and it’s marvelous!

There is also one non-trival advantage when using one system for 3-monitor-spanned gaming and another one for 3-monitor-no-spanned working. Switching between Surround/Eyefinity (spanning) would shuffle windows & icons when changed – doesn’t happen here.

Overall, it was new big thing for me and I’m very happy to have it. I’m definitely not crazy about ultra-wide monitors – these are too small for workplace (about size of 2 monitors) and would be very inefficient because of lack of angle if bigger, I hate the idea of curved ones, so there is really nothing better on market for me.

OQVEes5DaN-rMefsqEaIQg98eFXStf4zqTBouIhJArM=w1874-h928-noEdit: I forgot to add info about monitors used. So, there’s one BenQ G2450 in middle and BenQ GL2450 on sides (LED lighting). G2450 wasn’t accessible when I was ordering side monitors, so they have slightly different contrast/color, but are close enought to be good. These are nice for gaming (low/close to none input lag) and are *matte* which is omg-so big deal.

Ignoring hotplug monitor events on Arch Linux

Automatic hotplug event handling can be a problem, eg. when its run for monitors. I use HDMI splitter between my host OS and gaming VM and I didn’t like that my windows were all over the place when I’ve used it.

There are few ways to disable those (but still to be able to run them manually when needed!), but I’ve found only one method is able to run for all GPU drivers.

Most obvious method is xorg setting “UseHotplugEvents”. It’s great, but works only for Nvidia binary driver.

Section "Monitor"
# HorizSync source: edid, VertRefresh source: edid
Identifier "Monitor0"
VendorName "Unknown"
ModelName "BenQ G2450"
HorizSync 30.0 - 83.0
VertRefresh 50.0 - 76.0
Option "UseHotplugEvents" "False"

There is also similar setting but in this case, for Intel driver only.

Aside of both of that, there may be need to disable automatic xrandr events in your DE.
gsettings set org.cinnamon.settings-daemon.plugins.xrandr active false
gsettings set org.gnome.settings-daemon.plugins.xrandr active false

About this independent one (I use it with Nouveau) – option is to disable udev completely (for a while). That means that it also won’t work for dynamic USB devices, etc. But it’s good enough if you need to disable monitor discovery for a moment and can turn it on later again.

sudo udevadm control --stop

sudo udevadm control --start

KVM/QEMU Gaming Machine

I’m using Linux as my main OS for some time now and I’m almost perfectly happy about it. Why almost? Because I’m a gamer and I don’t like compromises. So even if I totally support Linux-gaming revolution which Steam/Valve brought I won’t quit playing games which I’d like to play just because they don’t have Linux version. I was WINE using a lot, but it still didn’t support a lot of my games.

For some time I dual-booted with Windows. It was very irritating, because it forced me to close all my opened software, wait to shutdown first OS, wait to boot my computer and then start second OS… It was so irritating that when I bought notebook capable of ‘so-so’ running games, I connected it to the second input of my main monitor and played games like Diablo 3 on it (running Synergy for comfort).

That, of course, wasn’t best solution – two machines running instead of one and also my laptop’s GPU is way worse then my desktop one (no surprise). However I haven’t figured out better way until I found some info about VGA Passthrough.

That magic solution was my remaining piece – with help of KVM and Qemu, it allows to create virtual machine with its own, fully accessible graphic card. Passing CPU power and memory wasn’t problem for VMs for years but for PCI devices such as GPU it’s kinda revolution.

How does it work exactly? I’ve got two graphic cards, but I’m not using SLI neither Crossfire – my Arch Linux (primary OS) only sees GeForce 9800 GTX+ card and it’s using it exclusively. Second GPU – AMD Radeon 4850 in my case – is visible only for virtual machine with Windows and is available only for it – which means it’s properly detected by AMD drivers without any performance drops which happens when GPU’s emulated.

I’ve not actually ran any benchmarks, because it works just great. When I installed Diablo 3 and it just flew on high settings, I knew that’s exactly the solution I was looking for. Some other games I tested, like Disciples 3 or Assassin’s Creed 3 (which is rather GPU-heavy) also run with no difference than on the Windows-only system.

Instalation wasn’t pretty and it forced me to compile kernel with custom patches for Linux, add few kernel parameters into GRUB, some script-fiddling and also I was fighting for while to use nvidia proprietary driver instead of open-source one. On the other hand, I used virt-manager tool to configure VM and it was very nice and easy to use. Just set-up how much CPU cores and memory I want to add, create file image for disk, few more click to passthrough some devices like mouse, keyboard, integrated sound and GPU obviously – then it’s ready.

Zrzut ekranu z 2014-11-22 23:47:28The only really painful thing about this technology is required hardware. It requires VT-x (or AMD-V on AMD processors) which are quite common CPU extensions, but also VT-D (or IOMMU), which are not. It’s easy to check which Intel chips have them (sad thing for powergamers – almost none with overlocking abilities), but it’s very hard to find motherboards which must also support both of them. It’s so risky business that people are making lists of working hardware.

I went with AsRock Z77 Extreme4 motherboard and Core i5 3550 CPU, which both were confirmed few times to work with VGA Passthrough and I can say that it was very good decision. They aren’t so pricey, yet I like them both very much already. :) I gave 2 of 4 cores and 3 of my 8 GiBs RAM to VM, but I’m going to buy another 4 GiBs and give it exclusively for VM(s). I’m also going to change Radeon 4850 for some more powerful, eyefinity-capable GPU in next year. I’ll also setup “Lintendo” gaming VM (propably with SteamOS) so I don’t need to change both GPUs. ;)

What can I say more? I highly suggest all Linux-loving gamers to take a look at this technology and build it for yourself if you’re tech-savy enough – it took me about 1,5 days to set this up, but a lot of work was done thanks to excellent creators of guides which I link below.

Guides and other helpful links:

PCI passthrough via OVMF [Arch]

KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9 [Arch]

{Guide} Create a Gaming Virtual Machine [Fedora]

HOW-TO make dual-boot obsolete using XEN VGA passthrough [Linux Mint]

Network adapter configuration for KVM / Xen on Arch

VT-D How-To [Xen Wiki]

VFIO tips and tricks [excellent blog – start with their FAQ]

Some tips from me:

  • There’s big “battle” between Xen and KVM/Qemu – I was going to start with Xen, but it lost compatibility with Nvidia blob driver some time ago.
  • Don’t give up when Radeon GPU is passed through and it gives “Code 43” error with Microsoft’s default drivers – just install AMD one and you’re set! Lost some hours when trying to fix non-existing issue.
  • It’s rather obvious to me now, but it’s needed to use DKMS on self-compiled kernels for Nvidia driver.
  • Virt-manager has good VNC viewer built-in which is helpful especially when you’re configuring input devices.
  • Synergy’s great for optimising number of input devices in that setup, but it had some weird behaviour when cursor was passed from Linux host to Windows guest – now I passthrough USB mouse and KB, then I run Synergy server on virtual machine to control Linux on other then center monitors.
    Just use “relative mouse movement” and “lock cursor to screen” in Synergy, works excellent.

How to pause & restore application with keyboard shortcut in Linux

Small thing, but very useful IMO – using these two easy script, it’s possible to pause and then unpause currently selected application with keystroke.

To me it’s often the case that I want have some program to be available the second I want it, but unfortunatelly it’s eating a lot of CPU and blocking another programs, which I actually use in the moment. So, I’ve created scripts to make this program available and ready for me, but cost only some RAM.

Use carefully – it can also pause you DE. :)

#by dRaiser

active_window_id=$(xdotool getactivewindow)
active_window_pid=$(xdotool getwindowpid "$active_window_id")
kill -n 19 $active_window_pid

#by dRaiser

active_window_id=$(xdotool getactivewindow)
active_window_pid=$(xdotool getwindowpid "$active_window_id")
kill -n 18 $active_window_pid

Save those scripts in some location (eg. ~/Scripts), make them executable by chmod +x filename and create a keyboard shortcut in keyboard settings of you DE (if you don’t use DE, I suppose you don’t need this tutorial).

In Cinnamon it looks like this:

pause_1 pause2

To not pause by mistake, I used ctrl+pause/break key for pausing and pause/break for restoring application (it does nothing when app’s not paused).

Apple Wired Keyboard on Arch Linux

Magnificient ArchWiki specifies optimal way to use Apple KB on Arch Linux, however because of some changes in udev module AUR package un-apple-keyboard doesn’t really work out of the box. Edit: Looks like it’s working okay now.

To make changes like:

  • Adds a /etc/modprobe.d/hid_apple.conf file which enables the F keys by default, as above.
  • Uses keyfuzz to remap F13-15 to PrintScreen/SysRq, Scroll Lock, and Pause, respectively
  • Swaps the ordering of the Alt and Meta (Command) keys to match all other keyboards, again using keyfuzz.
  • Applies these changes automatically when you plug in your keyboard, with a udev rule.

We’ve got to enable keyfuzz by systemctl enable keyfuzz and run additional keyfuzz script on boot. I just add execution to my /home/username/.bashrc file:

sudo keyfuzz -s -d /dev/input/by-id/usb-Apple__Inc_Apple_Keyboard-event-kbd < /etc/keyfuzz/apple_aluminium.keyfuzz

To make it execute passwordless it’s also needed to make light change in /etc/sudoers file, eg.

(... some lines)
username ALL=NOPASSWD: /usr/bin/keyfuzz

Also I experienced strange problem that holding left and down arrows sometimes doesn’t repeat key action. To workaround it there’s additional change on startup (so .bashrc again).

xset r 113; xset r 116

And now it’s perfect! Fn+F1-F19 button combinations are great to assign some additional functions also.

Source 1:
Source 2:

Nowe Cinnamon i Nemo – ściąganie napisów do filmów [QNapi]

Korzystam ze skądinąd popularnego DE Cinnamon, będącego forkiem GNOME-Shell, nakierowanym na “klasyczną” obsługę peceta. Jest bardzo łatwy w obsłudze i oferuje ogromne możliwości dostosowania go pod siebie. Używa domyślnie menedżera plików Nemo – forka Nautiliusa z kolei. Owy menedżer dotychczas cierpiał na brak możliwości podpinania akcji pod menu kontekstowe, przez co nie można było chociażby wygodnie ściągnąć napisów do filmu/odcinka serialu.

Pojawiła się nowa wersja Cinnamona (i Nemo), oznaczona jako 1.8, wspierająca Actions API, czyli właśnie akcje poprzez menu kontekstowe. Nie omieszkałem go wykorzystać i napisać prostego skryptu do ściągania napisów poprzez QNapi – oto i on: