Mardy (Posts about Linux)

Teaser: connecting Nintendo Switch controllers to the Wii

Alberto Mardegan — Sat, 11 Apr 2026 13:13:06 GMT

A few months ago I started playing with the Bluetooth controller embedded in the Nintendo Wii, to see if it was possible to get it to connect to other devices than just the Wii remotes. If you ask internet forums, you might fall into the impression that the Wii is not using a standard Bluetooth controller, or that it has been somehow "crippled" in order to restrict it to connect to the Wiimotes only, but that's not the case: it's an ordinary controller from its era, it's just that the Wii software (both the official SDK and the homebrew libogc) only uses it for the Wiimotes.

I first started looking into lwBT, the bluetooth stack used in libogc, but I quickly realized that it was impossible to get full control over the controller via this library: it has been adapted to work with the subset of the HID protocol used by the Wiimotes, and even if you can issue bluetooth commands to the controller via the HCI layer, you cannot receive the replies, since they are already intercepted by lwBT and there's no way to hook into them.

So I started writing my own little bluetooth stack, bt-embedded which from the ground up has been designed to be used by embedded devices and covering the use case of serving different clients running in a single process, and I've integrated it into embedded-game-controller (though this is not merged into the master branch yet) in order to allow connecting to bluetooth controllers. And in the last couple of days I've written a little ugly program to visualize the controllers in a 3D scene, in order to better test them:

Yes, the 3D model sucks, it was a nice model when I downloaded it from a free site, but then heavily reduced the number of polygons using Blender and went a bit too far; I'll do a better model later. The accelerometer information is not shown yet (I'd like to use it to actually tilt the controller, instead of using the joystick), but that will not be hard.

At the moment, the only supported controllers are the Nintendo Switch Pro controller (I'm using a clone here) and the Joy-cons, so there's still quite some work to do to add more.

It's been a journey in which I learned a lot about Bluetooth and USB and, who knows, maybe this will come handy in the future too.

Porting OpenGL games to the Nintendo Wii: chro.mono

Alberto Mardegan — Tue, 22 Apr 2025 15:35:25 GMT

More than one year has passed since my last blog post, and I'm a bit ashamed to confess that today's post is again about porting games to the Nintendo Wii — I always tell to myself that I'm soon going to move to something else, possibly less geeky than this (by the way, there is something else I could write about, but I'll leave it for another post!), but the problems posed by porting games to an old console are just way too stimulating, and my brain gets attracted to them in a way that I cannot resist.

Anyway, have you ever heard of OpenGX? It's a project aiming to write an OpenGL driver for the Nintendo GameCube and Wii's GX API: while these consoles have good (at the time, at least) 3D capabilities, they were programmed via an API not even remotely close to OpenGL, so back in 2013 one developer by the name of David Guillen Fandos started a project to investigate the possibility of wrapping the GX API in OpenGL. The project was abandoned after reaching a very basic state, but it's author was diligent enough to write a PDF file describing its design and some implementation details. Having bumped into this document, I was inspired by it and felt it was a pity that such a project had died -- especially given the fact that this didn't happen because of some technical infeasibility. So exactly one year ago, in the spring of 2024, I picked it up and tried porting the game BillardGL to the Wii; I had to add quite a few things to OpenGX, and adjusting the lighting pipeline, but after less than one month the port of BillardGL was ready. In the following months, I ported several other OpenGL 1.x games, gradually enhancing and expanding OpenGX, until I got most of OpenGL 1.4 supported.

A 23 year old game was just ported to a 19 year old console.

Should I have stopped there? Probably. Because indeed the Wii's GPU, despite allowing a good degree of complexity in setting up its shading engine (called TEV, Texture Environment), does not support the modern GL shading language, and trying to have the CPU compile the shaders into something that GX could understand is a task doomed to fail, in part because this would eat up all the computing power, but especially because there simply isn't an algorithm that could translate GLSL into GX commands. Is this the end of the journey then?

Well, the fact that OpenGL 2.0+ shaders can not be machine-translated into GX commands does not mean that this task is impossible: we've still got the human brain to use! The idea is the following: let the deveoper who is porting the game write the GX code corresponding to the GLSL code by hand. Saying it like this might feel like this is no better than saying “Just port the whole rendering backend to GX!” but as a matter of facts, there's a big difference: with this approach all the rest of the OpenGL code stays untouched, and the way I have design this shader substitution to work in OpenGX allows one to keep the GX code isolated in its own source file, without having to change a single line of the program, save from adding a line near the beginning (in main(), typically) to install the GX hooks. This means that your program will still call glUniform*(), glVertexAttribPointer() and so on to setup the rendering pipeline, but when the program will get to execute glDrawArrays() OpenGX will pass control to the hooks previously installed, which will receive the uniforms and the attributes, and setup the pipeline using GX commands. It might seem complicated, but it really isn't (well, if you can deal with the GX API), and it's even more efficient than the fixed pipeline of OpenGL 1.x, since here the GX commands are reduced to the bare minimum required by the shader, whereas in the fixed pipeline we have to follow predefined steps.

chro.mono running on a Nintendo Wii.

The first (and for the time being, the last) OpenGL 2.0+ game I've ported to the Wii is chro.mono, a nice puzzle game from 2013 whose source code has been released in 2021. It uses the FBO feature from OpenGL 3.0, so I had to implement it in OpenGX as well. I'm quite satisfied with the result, not only because the game runs at 60 FPS, but because it shows how rather complex shaders (the game has more than a dozen of them) can be realized in GX; to tell the truth, in couple of cases I had to implement the fragment shader by converting its code to C and drawing to a temporary texture, but luckily these shaders are used only during program startup to draw to an FBO and don't negatively affect the game performance. You can download it from here.

Summing up, if you get really bored and would like to engage in something unusual (read: useless), porting games to older consoles would definitely keep you active for some time. Unfortunately there aren't that many OpenGL games which are open source, so the candidates for porting are not that many (by the way, feel free to suggest in the comments — well, not for me, but maybe someone else will do it).

libSDL2 and VVVVVV for the Wii

Alberto Mardegan — Fri, 02 Feb 2024 17:50:44 GMT

Just a quick update on something that I've been working on in my free time.

I recently refurbished my old Nintendo Wii, and for some reason I cannot yet explain (not even to myself) I got into homebrew programming and decided to port libSDL (the 2.x version -- a 1.x port already existed) to it. The result of this work is already available via the devkitPro distribution, and although I'm sure there are still many bugs, it's overall quite usable.

In order to prove it, I ported the game VVVVVV to the Wii:

During the process I had to fix quite a few bugs in my libSDL port and in a couple of other libraries used by VVVVVV, which will hopefully will make it easier to port more games. There's still an issue that bothers me, where the screen resolution seems to be not totally supported by my TV (or is it the HDMI adaptor's fault?), resulting in a few pixels being cut at the top and at the bottom of the screen. But unless you are a perfectionist, it's a minor issue.

In case you have a Wii to spare, or wouldn't mind playing on the Dolphin emulator, here's the link to the VVVVVV release. Have fun! :-)

Will the internet forget russophobia?

Alberto Mardegan — Sun, 04 Jun 2023 07:41:02 GMT

I've often wondering what will happen when this horrific war in Europe will finally be over. I won't be discussing politics here, but what is mostly interesting to me is how (and if) all the companies who made high proclaims about not doing business with Russia will justify their getting back into the Russian market. They will probably count on the fact that the war will be long, and that people will forget what these companies' stance was. After all, the world has forget about all the companies who collaborated with the Nazi regime, so we can expect the same to happen with this war.

But I don't think that's right: if you made a mistake, you should be held accountable for it. You might be wondering what is the “mistake” I'm talking about: that's russophobia, indeed. To put it simply, and make a concrete example: if The Qt Company stops doing business with Russian companies and blocks its downloads page to Russian IP addresses because of the war, without being forced by the government to do so, but does not take similar measures against other countries who wage wars which have caused way more deaths and displacement of individuals, well, that's what I call “russophobia”. Of course, I'm aware that there's way more than that, and that the hatred for all what is Russian (including culture and sport competitions) is an even bigger issue, but in this blog post I'm especially focused on the IT world, so please forgive my semi-intentional narrow-mindness on this topic.

Now, I'm fully aware that we live in a mediatic bubble that directs our decisions in a way that is almost automatic, and I'm sure that most people working for companies who took russophobic decisions are not themselves russophobic at all (and I'm not dismissing the possibility that even the very same people who took these decisions might not be russophobic) and that these decisions were taken on impulse, because “everyone else is doing the same” and due to the media pressure that if you don't do that, you might get accused of supporting the “wrong” side of the war.

But that's not an excuse, especially for “smart” people like IT engineers (and I put the adjective between quotes for a reason), and especially after the initial heat has passed and when, after more than one year of war, we should have been exposed to different point of views and be able to evaluate the situation more rationally. It has been therefore especially stunning for me to learn that the Linux Kernel community, and hence The Linux Foundation, has recently given room to russophobic behaviours, refusing a patch coming from the Russian company Baikal (a CPU maker). For the record, the incriminated patch was not related to supporting hardware produced by this company (not that this would make the deed less serious, but at least one could have argued that there could be some spot of logic in it):

From: Jakub Kicinski <kuba@kernel.org>
To: Serge Semin <Sergey.Semin@baikalelectronics.ru>
[...]

On Tue, 14 Mar 2023 01:42:24 +0300 Serge Semin wrote:
> From: Serge Semin <Sergey.Semin@baikalelectronics.ru>

We don't feel comfortable accepting patches from or relating 
to hardware produced by your organization.

Please withhold networking contributions until further notice.

(here the link to the original discussion). One week later, someone denounced this as a violation to the Code of Conduct committee (unfortunately the only link I could find to this is coming from a Russian IT forum, and any other references seem to have been removed from DuckDuckGo and Google), only to receive a reply that it was all fine.

To me this is not fine. The war will end, sooner or later, but it bothers me that we never learn from the past and repeat the same mistakes over and over. We apparently know a lot about propaganda, yet we fail to recognize it when it influences our own mind and actions. My humble contribution is the creation of a page where I list the companies who have taken russophobic actions, and, on the opposite side, companies (like Flickr and Zorin OS) who have stood out for positive messages and helpful actions. My hope is that some of the listed companies will find the courage to review their actions, and either correct their stance, or at least clarify their reasons. So, I hereby present

Denouncing russophobia

where you'll find some of the good and some of the bad companies. I'm sure I'm missing plenty of them: I just started recollecting my memories and searching online a couple of days ago. I created this as a GitHub project, because indeed I'm looking forward for contributions, to help me make the lists more complete. I need to stress that the fact that a company has announced the suspension of its business in Russia does not automatically make it russophobic: what we need to look at is the reason for that decision: companies like LEGO and Nintendo, for example, have suspended their operations citing logistic and financial reasons; no judgement involved.

Let me repeat it once more, just to make sure there are no misunderstandings: it's perfectly fine for businesses to take a stance on politics, and sometimes it might be even praiseworthy; but if a company is international, and does not apply the same reasoning to other armed conflicts, or seem to care only about certain human rights violations and not others, then it's a case of double standards which we need to be aware of, and make the company think twice about it. And that's also the reason why you won't find any Ukrainian company among the “bad” ones, because in their case the reaction is perfectly understandable and they can hardly be accused of adopting double standards (well, technically speaking, they are adopting double standards, but when you are so directly impacted I think it does not deserve a blame): if it's your house which burns, you should definitely scream about it, even if you previously have been silent about your neighbour house's burning.

I'm especially looking forward for more “good” companies, who have shown empathy towards the people affected by the war (and maybe even collected money to help them) while refraining from taking the judging role and forgetting about all the injustice and suffering that other wars have caused (including on that very same piece of land that suddenly appeared on all newspapers' front pages on February 24th, 2022). I hope that these companies can serve as an example of positive action, humanity, and love.

MiTubo 1.4 adds feed folders

Alberto Mardegan — Mon, 10 Oct 2022 14:40:09 GMT

Exactly one month has passed since the previous release, just the right time needed to complete the feafure I've been working on since several weeks and to fix a few bugfixes introduced with the previous release. So it's time a new release of MiTubo:

I realized that I'm not that good at making release videos, but the point of the video above is to show that you can organize your feeds into folders. When clicking on a folder, a page opens with the folder's contents; but you can also directly click on a feed, as long as its preview is visible in the folder's delegate, and then the feeds open directly. This means that if you organize the feeds inside your folders so that the favourite ones are at the top, they'll also be visible in the folder preview and you'll be able to jump to them in just one click.

Maybe I'm not that good with textual explanations either, so why don't you check it out for yourself? ☺ Get it at mardy.it/mitubo (builds for Linux, Ubuntu Touch, Windows and macOS are available)!

MiTubo 1.3: sorting of QML ListView via Drag&Drop

Alberto Mardegan — Sat, 10 Sep 2022 10:38:51 GMT

One feature that I've been asked to add to MiTubo, and that indeed becomes more and more important as the number of subscriptions increases, is the ability to group subscriptions into folders. I've spent a good amount of time implementing the needed support in the C++ backend, which is now able to handle nested folders too, but given that building the UI parts was not a quick task and seeing how much time has passed since the last release, I thought of releasing a partial implementation of the whole feature, consisting only of the ability to manually sort the subscriptions via drag&drop (that, is no folder support). It turns out this is already not a trivial work!

I found a nice tutorial on ListView DnD sorting by the great Aurélien Gâteau which I found very inspiring, and while I didn't actually reuse the same code (mostly because I was already halfway through with my implementation, which I started before finding his tutorial), it was helpful to have it as a reference. I added a few animations to make it look more pleasant, and I'm rather satisfied with the result:

I'm not showing you the code yet (though, indeed, you can find it in the DraggableListView and DraggableDelegate items in the source repository) because it's not yet in a shape where it's generally reusable in other projects, but if I happen to need the same feature elsewhere I'll eventually try to turn it into a couple fully reusable components.

Anyway, here's what's new in this latest MiTubo release:

Subscriptions can be sorted by means of Drag&drop
For systems with python 3.5 or older (such as Ubuntu Touch), use the daily builds of youtube-dl instead of the official releases
Implement PeerTube search (this should reserve a post of its own!)

You can get it at the usual place. This time there are only Linux and Windows builds as I'm a bit lazy to make a macOS version, but should you need it, don't hesitate to ask!

MiTubo comes to macOS

Alberto Mardegan — Wed, 22 Jun 2022 19:44:47 GMT

I just released MiTubo 1.2. New in this version:

As suggested by alphas12 in the comments, I added the author name in the YouTube search results.
In the same results list, there's now a clickable link to the channel, which makes it easier to subscribe to it.
Improve layout of some pages on narrow displays (though there's still much to be done!).
Skip invoking youtube-dl if the video information is already encoded in the page HEAD meta properties.
Remember the preferred playback resolution; this can be helpful on low bandwith connections.
First macOS release!

While bringing in the macOS version, I updated the QScreenSaver library to support inhibiting the screensaver on macOS too.

I also tested the AppImage on openSUSE, and it seems to work fine there too. So, fewer and fewer people have valid excuses not to try out MiTubo!

MiTubo 1.1: screensaver inhibitor

Alberto Mardegan — Sat, 04 Jun 2022 10:46:54 GMT

Looks like I'm posting a bit too often about MiTubo, but don't worry, I'll soon find something else to write about.

Version 1.1 is now released, bringing you:

A screensaver inhibitor, at last!
AppImage now works in Arch and Manjaro

More in detail, this means that your computer won't go to sleep or start the screen saver while you are watching a video. To achieve this, I wrote a portable (well, for the time being it only supports Linux and Windows, but macOS support will eventually arrive too) library for inhibiting the screensaver: QScreenSaver. It lives in its own repository, and it's written in a way that should be easy to integrate with your own project. You are welcome to try it out (and add support for cmake/qmake/meson/…).

The AppImage support has been improved after a user filed a bug about MiTubo not working in Arch; I myself could not verify the issue as I've grown too lazy to install a distribution like Arch, but I did it on Manjaro (which is also based on Arch), and indeed the MiTubo AppImage contained some unnecessary libraries (while missing some others) that rendered it non-functional in those distributions. Now it's all fixed, so there's a good chance that the AppImage will work on your distribution, too.

MiTubo 1.0: playlist support, new “website”

Alberto Mardegan — Sat, 21 May 2022 12:53:56 GMT

Some news from the MiTubo world:

Version 1.0 has been released!
It's also available for Windows (boo!)
Some basic support for remote playlists
New “Check for updates” dialog
Added support for translations
Added Italian translation, of course
Minor cosmetic changes (like using a different unicode symbol for the “Back” button)
New web page for MiTubo

Expanding a bit on the points above, the first thing worth saying is that the choice of releasing this version as “1.0” does not mean that it's more stable than the previous ones; it just means that I'm rather satisfied with the feature set, and that I believe that the program is ready for more widespread use.

This is also the reason why I decided to prepare a web page for it: mardy.it/mitubo. I didn't go for a completely separate website, unlike what I previously did for Mappero Geotagger, PhotoTeleport and Imaginario (which reminds me that I haven't been working on the latter for a long time! I should try to correct this soon!), both because this way it's simpler to publish news about it (I'll continue doing that here, instead of cross-posting in two sites), and because having it in the same domain might be mutually beneficial for the SEO ranking of the blog and of MiTubo.

As for the Windows version, I want to thank once again the MXE project for their fantastic cross-compiling suite. I find it very cumbersome working in Windows, and being able to build my programs from Linux makes my life a lot easier (if you want to have more information about how this works with QBS, have a look at the previous MXE post). I wish there was something similar for macOS; and that's why the macOs version is going to take more time to arrive — on the other hand, I haven't received any requests for it, so I'm not in a hurry to work on that.

Last but not least, translation support means that if you want to help with translations, now you can. I've myself tried QtLinguist for the first time to write the Italian translation, and I found it to be an extremely effective tool, once you learn the key bindings by heart.

Mitubo 0.9: multiple concurrent video downloads

Alberto Mardegan — Thu, 05 May 2022 19:16:40 GMT

It will never stop surprising me how easy it is to implement big new features in a QML application! The assumption here is that the C++ part of the application should be well-written: objects should not be overloaded with unrelated functionalities just because it seems faster to code them that way, but one should rather design classes so that each exposes one functionality, and then QML and javascript act as the glue which binds all the parts together.

In a way, QML stands to C++ classes like the POSIX shell stands to command-line tools: a simple language which allows concatenating small units of functionality together to build a powerful program.

Anyway, that was not what I wanted to talk you about today. ☺ Today's post is about MiTubo, whose version 0.9 has been released today:

The big feature in this release is download of audio/video files: I thought, since I'm using yt-dlp (or youtube-dl on Ubuntu Touch) anyway for extracting video streams, why not add an option to let users download the media content? This turned out to be easier than expected, so if you were looking for a graphical frontend to the YouTube downloader, well, now MiTubo is an option you could try.