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! :-)

0 0

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.

0 0

At the moment OMP (the company developing Aurora OS) is mostly (or even exclusively, AFAIK) targeting business customers, meaning corporations such as the Russian posts and the railway company, whereas the consumer market is seen as something in the far away future. Just in case you were curious whether there were any devices on sale with Aurora OS.

I should also explain why I've refused several very well paying job opportunities from Western companies: it's actually for a reason that has been bothering me since last March, and it's a very simple one. The fact is that because of the sanctions against Russia I already had to change bank once (as the one I was using fell under sanctions), and in these months I've always been working with the fear of not being able to receive my salary, since new sanctions are introduced every month and more and more banks are being added to the blacklist. That's why I've restricted my job search to companies having an official presence in Russia; and to my surprise (and from some point of view, I could even say disappointment) the selection and hiring processes were so quick that I received three concrete offers while I was still working my last weeks at Canonical, and I joined OMP on that very Monday after my last Friday at Canonical.

I mean, I could have rested a bit, at least until the Christmas holidays, but no. ☺ Anyway, I'm so far very happy with my new job, and speaking Russian at work is something totally new for me, both challenging and rewarding at the same time.

0 0

Some months ago I finished reading Dostoevskiy's “The Idiot”, a book about an exceedingly good-hearted man, prince Lev Mishkin, whose behaviour was puzzling the people around him so much that they thought of him as an idiot. Sure, the fact that he was suffering from epilepsy didn't help, but it was far from being the primary reason for their thinking, since his epileptic seizures were very rare (if I remember correctly, only two occurred during the time of the story) and everybody's opinion had already formed well ahead of witnessing him in such a state.

He was an idiot because he was open, trustful, and especially because he could not “read between the lines” of what was been said to him: his social conduct was straight, and although he was following at his best the customs that he had been taught, he was supposedly awkward and unable to perceive and parse all the messages that are implicitly conveyed by social behaviours and human interactions. I added the word “supposedly” because, as a matter of fact, his behaviours were all perfectly normal for me: I only noticed their awkwardness when it was pointed out by the other characters, at which point I couldn't help smiling and acknowledging that, indeed, that thing he did was weird.

However, he was a good and caring person, and not without talents: he had an interest in calligraphy, and everybody liked to listen to him, as his speech was insightful and his thoughts were original. I wonder how many of my readers can identify themselves in such a character?

I definitely can. I won't get into the details, but I've felt many times on me the amused or puzzled glance of people (like that time in high school when I could not open a door in front of dozens of people, and I heard them say “So, that guy is the genius of mathematics?” — I'll never forget that!), often without understanding the reason for their reactions. Still, generally people seem to like my company and be genuinely interested in talking to me.

So, what's wrong with prince Lev Mishkin, me, and maybe with you too? Well, a few things, I would say. I'm not going to claim any scientific truth on what I'm going to say, these are just my own impressions and deductions, which seem to be shared by other people in the interwebs too, judging from a quick search I did; take them for what they are.

The first thing I notice is some common traits between us and autistic people: we tend to work better with things, rather than with people; we can focus on a certain thing (work, a mathematical problem, a game) and forget about the world around us; we have our unique hobbies, like solving puzzles, arguing about a specific and very narrow topic, learning artificial (both human and programming) languages; it's as if we needed to build a small, better world where we would feel safe and at ease.

The other thing, which I actually consider harmful and which I put efforts to change in my own life, is the fact that it's extremely easy to get us interested into a specific aspect of a problem, and make us forget (or just not notice) the big picture. That small part that we are looking at is stimulating and challenging, and we are led to think that it's core of the issue, and maybe of all the issues that affect our world. What is often missing is the ability to take one step back and try to look at the issue from a different angle, and especially the ability to listen for counter arguments; I mean, we do listen to them, but since we have, in a way, “gamified” the issue, even when we think that we are open to listen to the other side, we are in reality trying to win the counter-arguments, rather than genuinely trying to understand them.

Another thing which we have, is faith. Yes, you read it right: even though the IT world is probably the one with the highest percentage of atheists, men always need something to believe in. We just don't realize it, but we do hold a blind trust in certain persons and authorities. This does not mean that this trust lives forever and cannot be broken, but this generally does not occur because of a conscious realization of ours. Much more often than we'd like to admit, the reason why we lose faith in a certain person or authority is because the rest of the persons and authorities that we trust has told us so. In other words, even if there's undoubtedly a reasoning of our own, the full realisation and conviction occurs after having collected and compared the opinions (or statements) of those we trust. The net result is that the IT population is the one most trustful of the mainstream media, because it's the mainstream media who has more “voice”: that's where the most reputable journalists, scientists, activists are (and “reputable” is the key word here, since this reputation is recursively created by the mainstream media themselves or by their sponsors).

I might be biased by my own experience here, but it seems to me that there isn't a group of people more homogenous in their political (and generally, world) views than that of IT workers. When, in 2018, I saw the leaked video of Google's co-founder Sergei Brin and other executives' reaction at Trump's presidential victory, what I found most surprising was not the contents of the speech, as they were mostly mainstream opinions, but rather the fact that all this could be said in a company meeting. Something like this, I though, could never happen in an European company, as political matters are a conventional tabu in the work environment. But the point is that Brin and others could say those words only because they knew that the overwhelming majority of the audience shared the same opinion. I don't think you could find the same homogeneity of thought among shop assistants or philosophy professors.

Assuming that you have followed me this far into my rambling, and that you recognize that there might be some truth in what I wrote, you might now be wondering if there's a way to counterbalance our “idiotic” traits. Unfortunately I don't have a full answer, as myself am only halfway there (but maybe I'm too optimistic here? and does this road even ever end?), but there are a few things that I think are absolutely worth trying:

• Talk with people. Better if face to face, or at least in a video call; just 1-on-1, avoid groups, or you'll get on the defensive and try to defend your position for the sake of not losing the argument in front of an audience. But it's not a fight. Your goal when talking should not be that of convincing or getting convinced, but rather just to understand the other points of view.

• Read both sides of the narrative. Try to see the other party's argument as they themselves present it, and not how it is presented in the media you usually read. Media often use this trick, to either invite “clown representatives” of the other point of view just to ridicule it, or they give them too little time, or extrapolate their answer out of context, just to make them appear unsensible.

• Always assume that other people are smart, and that no one is bad.

• Whatever the argument, try to answer the key question: “Cui bono?” (who profits?) to be at least aware of all the hidden interests behind this and that. They don't necessarily invalidate a position, but they must be considered.

• Lose faith. The only faith you are allowed to keep is the faith in God (or Gods), if you have it: but men, theories, institutions, authorities (including religious ones!), these must always be assumed to be imperfect and not blindly trusted. People serve their interests or can be manipulated. Try always to start from a clean table and an empty mind, and see if they have enough arguments to convince you.

• Do never assume “They can not all be wrong” or “If this were wrong, at least some media would report it”. It just doesn't work this way, this is again a matter of having faith in the majority. Think of how many times in (recent) history you were presented an unambiguous truth, which later came out to be a scam (Iraq war being a famous one).

• Defocus. You might be spending a lot of energy into something that's not worth it. I mean, feel free to pursue whatever hobbies you like, as long as they make you feel better. But if you think you have a mission, think twice about it. Think about the world you'd like to live in, and whether/how this mission contributes to it.¹

• Ask questions. Be curious. Be challenging. For any topic, there are questions that have not been answered in mainstream media². Find the answer, then find explanations, never stopping at the first satisfactory one, but always get at least two competing answers. From here, ask more questions, rinse and repeat. And at every step ask yourself this: why didn't I know about this? Is someone trying to hide the truth from me?

• Aim at improving. Whenever you read something or talk to people, keep a humble attitude and try to be challenged. Your goal should be that every reading and every dialog should make you wiser, even if what you initially read and heard sounded like garbage. There are always reasons for all these thoughts you disagree with.

• Reach out to the people nearby. Try not just to be sympathetic to the needs of some population living far away from you, which the media has singled out as being those needing your compassion, and try instead (or in addition to that) to be sympathetic and helpful to the people around you. To your neighbours, to those you see in the public transport and, first and foremost, to your relatives.

Summing up, what I want you to realize is that we IT workers are easily exploitable. All those thought manipulation techniques represent a problem to everyone, but it's particularly with us that they tend to be especially effective; as a matter of fact, I've found that awareness of how the power controls us is higher among uneducated people, because they are more distrustful of the media and just tend to consume less of it. We, on the other hand, are not only well educated to respect the authority (see Noam Chomsky on education), but our logical, detail-focused mind can be easily externally controlled by continuously stimulating it to focus on specific things and not others.

How would Dostoevskiy call us?

0 0

But fear no more, Deride is here!

I won't spend too many words describing it, since you can read its description from the link above, where you will also find some example code. More examples, by the way, can be found in the example/ folder in the code repository, where you can see how it can be used to mock both pure C++ and QObject-based classes, and C libraries.

What is most important for me to say now, is that the project is in alpha state, meaning that I've tried it on a handful of header files only; it's highly likely that it will not work on many real-life scenarios, and if that happens I warmly invite you to inform me by filing a bug report providing the include file that was not properly processed.

I leave you with a short example of a unit test, written using Deride. The class under test is called Stable, and internally it uses objects of type Horse, that we decided to mock. We used Deride to generate the mocked implementation and a MockHorse class which can be used to control the mocked objects. When building the test, we won't link against the original horse.cpp, but we'll only use the original horse.h; the implementation will be found in mock_horse.cpp, generated by Deride. And in the corresponding mock_horse.h file we'll find the MockHorse class with all the on<method>Called() hooks which we can use to install our callbacks (either to reimplement the object behaviour, or to just be notified on when its methods are called).

    /* This MockHorse is the object created by Deride
     *                   |
     *                   |
     *                  \|/
     *                   V
     */
    using Mock = Animals::MockHorse;

    std::list<std::string> horseNames = {
        "Tom",
        "Dick",
        "Harry",
    };

    /* We could use a vector, but let's be explicit */
    Mock *mockTom;
    Mock *mockDick;
    Mock *mockHarry;

    int createdHorses = 0;
    // onConstructorCalled() is created by Deride and called when the mocked
    // Horse object is created
    Animals::MockHorse::onConstructorCalled([&](const std::string &name) {
        std::cout << "Horse instantiated: " << name << std::endl;
        createdHorses++;
        if (name == "Tom") {
            mockTom = Mock::latestInstance();
        } else if (name == "Dick") {
            mockDick = Mock::latestInstance();
        } else if (name == "Harry") {
            mockHarry = Mock::latestInstance();
        } else {
            assert(false); // should not be reached
        }
    });

    Stable stable;
    stable.createHorses(horseNames);
    /* It's at this point that the contructor callbacks we defined above will
     * have been called. Let's double-check that indeed that's the case.
     */
    assert(createdHorses == 3);
    assert(stable.count() == 3);
    assert(mockTom != nullptr);
    assert(mockDick != nullptr);
    assert(mockHarry != nullptr);

    /* Prepare for mocking the jump; these methods are generated by Deride and
     * allow setting the return value for the corresponding jumpHeight() method
     * from the original Horse class. */
    mockTom->setJumpHeightResult(1.5);
    mockDick->setJumpHeightResult(1.7);
    mockHarry->setJumpHeightResult(1.3);

    std::string highestJumper = stable.findHighestJumper();
    assert(highestJumper == "Dick");

In my closing words I'd like to thank the Clang project, which Deride is using to parse and interpret the input files, and Jinja2, the templating engine used to generate the mock code.

0 0

It was relatively easy to get the FM radio to work on this phone: I can now tune to a frequency and see that the RDS data is received, but I cannot get any sound out of the speakers or headphones, which makes the whole radio experience a bit, uhm… suboptimal, let's say.

The problem is not new: back in the days when Ubuntu Touch was still supported by Canonical, sturmflut was trying to get the FM radio to work, and he met the same issues (see this and this messages in the mailing list). He also spent some time investigating how the Factory mode works (the FM radio is indeed one of the features that can be tested via the Factory mode, and it does work) and he mentioned that he could get gdb to attach to the factory mode program and could see the various ioctls being executed. Yesterday I tried to follow the same steps, but I failed quite soon: I simply could not connect with adb shell while the device was in factory mode, so no chances of debugging for me. ☹

Out of dispair, I tried just to manually run the program /system/bin/factory inside a Lomiri session and, to my surprise, it overlayed its yellow “Factory Mode” title on the screen — just to immediately quit afterwards. I tried running it with strace, and noticed these lines:

open("/sys/class/BOOT/BOOT/boot/boot_mode", O_RDWR|O_LARGEFILE) = 15
read(15, "0\n", 4)                      = 2
close(15)                               = 0
writev(5, [{"\3", 1}, {"FTM\0", 4}, {"[FTM UTILS] Unsupported factory "..., 39}], 3) = 44
writev(5, [{"\6", 1}, {"NVRAM\0", 6}, {"[MAIN] Unsupported Factory mode\n"..., 33}], 3) = 40

Of course, the /sys/class/BOOT/BOOT/boot/boot_mode file is read-only, so I couldn't just write 1 into it, but could a bind-mount work? Indeed it did! And after a few attempts, I verified that writing a value of 4 in the boot_mode file made the factory program happy. It was still unusable because it was acting as if the volume down button was being constantly pressed, so the cursor was always moving downwards, but killing the Lomiri session did the trick. In short, these are the steps you need to follow in order to run the Factory Mode from an ordinary boot session:

sudo -i  # become root
echo 4 > /tmp/trick
mount -o bind /tmp/trick /sys/class/BOOT/BOOT/boot/boot_mode
service lightdm stop  # wait a few seconds until this returns
unset LD_PRELOAD
/system/bin/factory

What is more surprising, is that the FM radio test is working even in this environment, and you can actually hear the sounds (for some reason, the FM radio item takes about 40 seconds to initialize when run under these conditions, but it eventually works). At this point, not only I could run gdb (which I didn't), but I could even run the factory program under strace and collect the logs.

At the moment of writing this post, I haven't yet examined the logs, so I'm not at all sure that they'll be enough to make audio work (I suspect that the factory mode binary might be playing some tricks that are somehow not replicable in a proper Linux system with Pulseaudio and lots of other services running), but I do have enough information to make at least a few attempts.

Stay tuned, and have a Merry Christmas!

0 0

This post is a quick summary of my investigation, which should serve as a note keeper for when I'll actually get to implement the feature.

The Android story

It was a bit surprising to find out that Android does not offer an API to use the FM radio, meaning that we cannot simply expose an API via libhybris. Every manufacturer is therefore choosing their own API, and Android applications are most often developed for a specific chipset family, or need to carry the code to support all the various devices.

For example, I found the RFM Radio Android application which supports a few Qualcomm Snapdragon processors, for which the FM radio functionality is exposed by a kernel driver via the V4L API. This means that the FM radio is probably working out of the box with QtMultimedia's QRadioTuner. Unfortunately the Note 7 Pro uses a newer Snapdragon, and even after some days of investigations I couldn't find out how the radio driver communicates to the userspace; but more on this below. Other chipsets offer other APIs, and I was glad to find that someone already wrote a Ubuntu Touch FM radio application for the Volla phone, which has a Mediatek board.

Anyway, the lack of a unified FM radio API is probably the reason why most of the so-called “FM radio” applications on Android are not really using the FM radio but rather streaming audio from the internet.

The FM radio in the Note 7 Pro

Before I start talking about a phone that no one cares about, let me say that what I'm going to write applies to several other Snapdragon chipsets and could be relevant to other phones. For one, the Redmi Note 9 Pro uses the very same bluetooth chipset as the Note 7 Pro (and in case you are wondering why I mentioned bluetooth, it's because the FM radio functionality is delivered by the same BT chip), so all what I'm going to write here is also relevant for that phone.

In order to figure out how the radio worked on this device, I took the drastic decision to reflash the stock Android (well, MIUI), started the preinstalled FM radio application, and meanwhile looked at the logcat messages (I'm not sure if this is needed, but before doing so I went to the “Developer options” in the system settings and set the debugging level to the maximum). Among a lot of noise, this showed me lines like these:

I android_hardware_fm: Opened fm_helium.so shared object library successfully
I android_hardware_fm: Obtaining handle: 'FM_HELIUM_LIB_INTERFACE' to the shared object library...
D FmReceiverJNI: init native called
D android_hardware_fm: BT soc is cherokee
I android_hardware_fm: Init native called
I android_hardware_fm: Initializing the FM HAL module & registering the JNI callback functions...
D radio_helium: ++hal_init
D fm_hci  : ++fm_hci_init
I fm_hci  : hci_initialize

Well, even without knowing nothing about all what these lines meant, I had something I could search the internet for. So I found the Qualcomm FM code in CodeAurora, and search for the code relative to my Snapdragon 675 (aka sm6150). I quickly gave up on trying to make some sense out of the git tag naming in that repository, and just tried to search for a tag which could be referring to my device. I found one, and started browsing its source tree.

It turns out that Qualcomm provides a Java package which applications can use, and which internally dlopen()s the fm_helium.so library, which in turn depends on the libfm_hci.so library. I had a quick look at the source code of these libraries, which are also present in the repository, but decided that I would have had more chances of success if I just tried to follow the JNI code, and in particular the android_hardware_fm.cpp file. I'm not sure why this code is not using the C structure types defined in the headers provided by the helium library, and instead redefines all the constants and accesses the character buffers by offsets — it might be just for historical reasons — but in any case I decided to follow along.

The fm-bridge program

Since we have a rather net separation between the Ubuntu Touch and the Android worlds (the Android services are running inside an LXC container, with all their Android libs and dependencies), one should not attempt to write an Ubuntu process that loads the Android libraries, because the libc used in Android is different, so things are likely not to work. But we can have Ubuntu and Android processes communicate over a socket or other kind of IPC; so, what I decided to go for, is writing a small C program that will live in the Android side, it will talk to the FM radio (via helium_fm), and accept commands / give replies via its stdin / stdout.

I unimaginatively called it “fm-bridge”, and you can look at its horrible code here. Really, I just said it was terrible, so why did you look at it? I definitely need to rewrite it from scratch, possibly using the helium headers, but as a proof of concept this also works. Then I carefully examined the logcat output while using the MIUI FM radio application in Android, and figured out what was the command sequence I had to input into fm-bridge's standard input in order to have it tune onto a given frequency. I'm publishing the commands here too, should I ever lose my notes:

enableSlimbus 1
setControl 0x8000004 1
enableSoftMute 1
setControl 0x8000029 0
setControl 0x800000c 1
setControl 0x800000d 1
setControl 0x800000e 1
setControl 0x800002b 0
setControl 0x8000007 4
setControl 0x8000006 0x40
setControl 0x8000006 0x40
setControl 0x8000011 0
setControl 0x800000f 1
getControl 0x8000010
setControl 0x8000010 0xef
setControl 0x800000f 1
setControl 0x800001b 1
setControl 0x8000012 0
setFreq 89300
setMonoStereo 1

I'm sure that not all of them are needed, but I'll figure out the optimal sequence later. In order to use this program on Ubuntu Touch, I had to alter the vendor partition to add this program, but also the fm_helium.so and libfm_hci.so libraries (more on that below).

When feeding the above commands to the fm-bridge in Ubuntu, I saw that I was getting a logcat output similar to the one from Android, which was mildly comforting. No sound was comint out of the speaker or out of the earplugs, but I was hardly expecting it all to work at the first try. And I got convinced that the FM tuner was indeed working, because typing the command “startSearch 1” made a new frequency appear in the logs, proving that the tuner had found another station and tuned onto it.

Getting the sound out

This was actually the easiest of the steps, thanks to the Ubuntu Touch FM radio application we have for the Volla: its source code mentions a few pulseaudio commands that worked perfectly in the Note 7 Pro too, despite the fact that the underlying chipset is totally different. This should not be as surprising as it might sound like, given that Android has a common audio API.

Just for my future reference, the commands are these:

pacmd set-source-port 1 input-fm_tuner
pactl load-module module-loopback source=1 sink=0

Ta-daaa! The radio was now playing from the phone loudspeakers! It was indeed quite loud, and the volume buttons did not seem to have any effect on it, but the volume can be controlled with pulseaudio:

pactl set-source-volume 1 50%

Of course, if we ever manage to make this into an Ubuntu Touch feature, we'll have to find a way to make the volume respond to the volume buttons.

Addind the needed files to the vendor partition

The simplest approach (and the one I took initially) is that of downloading the vendor.img into your PC, loop-mounting it, adding the fm_helium.so, libfm_hci.so and fm-bridge files to it and then umount the partition and reflash it (remembering to converting it from/to a sparse image before downloading/uploading it). This approach works flawlessly, but I'm wondering if one might incur into issues if the version of the NDK used to compile fm-bridge is different from the one that was used to compile the other vendor binaries, so I decided to give it a try to build the whole vendor partition myself.

This turned out to be a non trivial process, because I was using the Halium tree to build the vendor image, and not the LineageOS which was used to build the vendor image for my device: I could make an image, but it took some time before I figured out which were the needed packages that somehow got lost because of the Halium changes and that had to be added to the Makefile.

To help my weak memory, I expanded the README file in the violet port with the steps needed in order to build the vendor image.

A system service for the FM radio

While it could be possible for Ubuntu Touch applications to directly access the FM radio device in the same way that Android applications do, this is suboptimal for a few reasons. Even if we provided a shared library to deal with the various radio chipset implementations, the application would either need to be unconfined, or we'd had to provide an ever-changing AppArmor profile that peeks new holes every time that a new device implementation is added (and what if this implemenation uses a generic kernel device, which could be used for other goals too?) and in any case we'd have to make this policy restricted, since the RDS data provided by the radio stations would reveal the user location (well, the city at least) to the application. Not to talk about concurrent access to the radio device if two applications attempt to use it.

Therefore, my proposition (and what I'll implement, if I'll live long enough or if someone doesn't beat me to it) is to have a system service deal with the various hardware differences and expose a D-Bus API that will be hooked up as a QRadioTunerControl plugin, so that Qt applications will be able to just use the QtMultimedia APIs to access the radio.

The service would also need to talk to the trust-store, to let the user decide whether the application should really be granted access to the FM receiver (and when using the turst-store, this decision is remembered, and revocable from the System Settings's Security panel). Of course we'll also need to add a fm-radio AppArmor policy to let applications use this service.

0 0

A quick search in the internet did not provide a clear answer: I found a Qt HTML parser in (stalled) development, and a few other C++ or C parsers (among the latters, lexbor is the most inspiring), but all of them seem to take the approach of parsing the HTML file into a DOM tree, while I was hoping to find a lightweight SAX-like parser. Pretty much like Python's html.parser.

Anyway, I don't remember how it happened, but at a certain point I found myself looking at html.parser source code, and I was surprised to see how compact it was (apart, of course, for the long list of character references for the HTML entities!). Upon a closer look, it also appeared that the code was not making much use of Python's dynamic typing, so, I thought, maybe I could give it a try to rewrite that into a Qt class. And a few hours later QHtmlParser was born.

As this post's title suggests, the process of rewriting html.parser with Qt was quite straightforward, and the nice thing about it is that I didn't have to spend any time reading the HTML standard or trying to figure out how to implement the parser: I just had to translate Python code into C++ code, and thanks to the nice API of QString (which in many ways resembles Python's — or vice versa) this was not too hard. I even left most of the original code comments untouched, and reused quite a few tests from the test suite.

It was time well spent. :-)

If you think you might need an HTML parser for your Qt application, you are welcome to give it a try. It's not a library, just a set of files that you can import into your project; for the time being I only have a build file for QBS, but I'll happily accept contributions to make it easier to use QHtmlParser with projects built using other build systems. You can see here the changes I made in MiTubo to start using it and detect RSS feed in a webpage's HEAD.

That's all for now. And in case you missed the link before, you can find QHtmlParser here.

0 0

The good news is that I've done some progress; the bad news is that there are still plenty of issues, and solving them involves deep diving into nearly all components and technologies that make up the core of an Android device, so completing the porting is going to take quite some time. On the other hand, I'm learning a lot of new stuff, and I might be able to share it by writing some documentation. And, who knows, maybe work on some other device port.

Anyway, enough with the introduction! Let's see what progress I've been doing so far.

The new device tree

While asking for help to debug the audio issue I was facing (more about that later), I was also told that the lavender tree, which I was using as a reference, was obsolete. The new one was in gitlab, and was build with a totally different system, described here.

So, I picked the lavender tree and adapted it for violet: I changed the deviceinfo file to point to my kernel tree, use my kernel configuration, and use the same boot command line as before. By the way, here's my current "new" device tree. The build failed, with errors like:

In function 'memcpy',
    inlined from 'proc_ipc_auto_msgmni.part.1' at /home/mardy/projects/port/xiaomi-violet/bd/downloads/android_kernel_xiaomi_violet/ipc/ipc_sysctl.c:82:2:
/home/mardy/projects/port/xiaomi-violet/bd/downloads/android_kernel_xiaomi_violet/include/linux/string.h:340:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
    __read_overflow2();
    ^

I then replayed the kernel build using the old system, and noticed that it was using clang as the compiler; so I changed the related flag in the deviceinfo file, and the build went past that point. It failed later, though:

/home/mardy/projects/port/xiaomi-violet/bd/downloads/android_kernel_xiaomi_violet/drivers/staging/qcacld-3.0/core/sap/src/sap_fsm.c:1498:26: error: cast to smaller integer type 'eSapStatus' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
                bss_complete->status = (eSapStatus) context;
                                       ^~~~~~~~~~~~~~~~~~~~

I ended up editing the Kbuild file in the module source directory, and removed the -Werror from there (as well in another place that failed a bit later). This made the build proceed until the end, where it failed because the device tree file was not found:

+ cp -v /home/mardy/projects/port/xiaomi-violet/bd/downloads/KERNEL_OBJ/arch/arm64/boot/dts/qcom/sm8150-mtp-overlay.dtbo /home/mardy/projects/port/xiaomi-violet/bd/tmp/partitions/dtbo.img
cp: cannot stat '/home/mardy/projects/port/xiaomi-violet/bd/downloads/KERNEL_OBJ/arch/arm64/boot/dts/qcom/sm8150-mtp-overlay.dtbo': No such file or directory

I quickly realized that this was due to an error of mine: the Xiaomi violet is a sm6150, not a sm8150 as mentioned in my deviceinfo file! But what overlay file should I use then, since there isn't a sm6150-mtp-overlay.dts in my source tree? Having a loot at other deviceinfo files, I saw that the deviceinfo_kernel_dtb_overlay line is not always there, so I tried commenting it out, and it helped.

The next step was getting flashable images, of course. While the device is not supported by the UBports system-image server, we can use use some scripts to create a fake OTA (Over The Air update) and generate flashable images starting from it. The steps can be read in the devel-flashable target of the .gitlab-ci.yml file (if this step is not present, we should try to find another device repository which has it. They are the following:

./build/prepare-fake-ota.sh out/device_violet.tar.xz ota
./build/system-image-from-ota.sh ota/ubuntu_command out

Once these commands have completed their execution, these commands will push the images to the device:

fastboot flash boot out/boot.img; fastboot flash system out/system.img

There's also fastboot flash recovery out/recovery.img, but I left it out since I was not interested in the recovery image at this stage. And unless you are ready to submit your port for inclusion into the "supported devices" list, I'd recommend not flashing the UT recovery image since TWRP is more powerful and will likely help you in recover your device from a broken image.

Kernel command line

It's important that the kernel command line contains the systempart parameter. In my case, the first boot failed because the command line was longer than 512 bytes, and this parameter was getting truncated. So one thing to be careful about is the length of the kernel command line.

This was fixed by removing some unnecessary kernel parameters from the deviceinfo file.

Missing thumbnails in the Gallery app, content-hub not working

Another issue I noticed is that photo thumbnails were all black in the Gallery app, and the content-hub also was not working. I noticed a relevant commit in the lavender kernel tree and found a launchpad bug which mentioned the issues I was seeing. In the Telegram channel I was told that patch is a forward port of a commit from kernel 3.4 that was present in all of the cores devices, and that it was indeed needed to have the ContentHub working.

The patch did not apply cleanly on top of my kernel tree, but luckily it was just an offset issue: adjusting the patch was easy, and indeed after applying it thumbnails started appearing in the Gallery and Imaginario could import photos again via the ContentHub.

Time and date

Time was always reset to a far away date after a reboot. This is a common issue on Qualcomm devices, and can be fixed by disabling the time service in the Android container.

https://github.com/Halium/android_device_halium_halium_arm64/pull/3

For some reason, at a certain point my override stopped working (or, more likely, the override never worked, but I happened to have fixed the issue directly modifying the vendor init file). I had to copy /android/vendor/etc/init/hw/init.qcom.rc into /usr/share/halium-overrides/, modify it and bind mount the modified file in order to get it working.

This actually seems to match my understanding of the Android init documentation, because according to the path priorities a configuration file stored under /system/ will never be able to override one stored under /vendor.

Fixing the audio configuration

Audio was not working at all. The sound indicator icon was not shown, only the raw (unstranslated) "indicator-sound" text was shown in the panel. pulseaudio was not running. Trying to run it manually (as the phablet user, since pulseaudio is run in the user session) led to this:

phablet@ubuntu-phablet:~$ pulseaudio -n -vvv -F /etc/pulse/touch-android9.pa
I: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
...
D: [pulseaudio] cli-command.c: Parsing script '/etc/pulse/touch-android9.pa'
D: [pulseaudio] database-tdb.c: Opened TDB database '/home/phablet/.config/pulse/ubuntu-phablet-stream-volumes.tdb'
I: [pulseaudio] module-stream-restore.c: Successfully opened database file '/home/phablet/.config/pulse/ubuntu-phablet-stream-volumes'.
...
D: [pulseaudio] module.c: Checking for existence of '/usr/lib/pulse-8.0/modules/module-droid-card-28.so': success
I: [pulseaudio] module-droid-card.c: Create new droid-card
D: [pulseaudio] droid-util.c: No configuration provided for opening module with id primary
I: [pulseaudio] config-parser-xml.c: Failed to open file (/odm/etc/audio_policy_configuration.xml): No such file or directory
D: [pulseaudio] droid-config.c: Failed to parse configuration from /odm/etc/audio_policy_configuration.xml
D: [pulseaudio] config-parser-xml.c: Read /vendor/etc/audio/audio_policy_configuration.xml ...
D: [pulseaudio] config-parser-xml.c: New module: "primary"
W: [pulseaudio] config-parser-xml.c: [/vendor/etc/audio/audio_policy_configuration.xml:78] Could not find element attribute "samplingRates"
E: [pulseaudio] config-parser-xml.c: [/vendor/etc/audio/audio_policy_configuration.xml:78] Failed to parse element <profile>
E: [pulseaudio] config-parser-xml.c: parsing aborted at line 78
D: [pulseaudio] droid-config.c: Failed to parse configuration from /vendor/etc/audio/audio_policy_configuration.xml
D: [pulseaudio] config-parser-xml.c: Read /vendor/etc/audio_policy_configuration.xml ...
D: [pulseaudio] config-parser-xml.c: New module: "primary"
W: [pulseaudio] config-parser-xml.c: [/vendor/etc/audio_policy_configuration.xml:78] Could not find element attribute "samplingRates"
E: [pulseaudio] config-parser-xml.c: [/vendor/etc/audio_policy_configuration.xml:78] Failed to parse element <profile>
E: [pulseaudio] config-parser-xml.c: parsing aborted at line 78
D: [pulseaudio] droid-config.c: Failed to parse configuration from /vendor/etc/audio_policy_configuration.xml
I: [pulseaudio] config-parser-legacy.c: Failed to open config file (/vendor/etc/audio_policy.conf): No such file or directory
D: [pulseaudio] droid-config.c: Failed to parse configuration from /vendor/etc/audio_policy.conf
I: [pulseaudio] config-parser-xml.c: Failed to open file (/system/etc/audio_policy_configuration.xml): No such file or directory
D: [pulseaudio] droid-config.c: Failed to parse configuration from /system/etc/audio_policy_configuration.xml
I: [pulseaudio] config-parser-legacy.c: Failed to open config file (/system/etc/audio_policy.conf): No such file or directory
D: [pulseaudio] droid-config.c: Failed to parse configuration from /system/etc/audio_policy.conf
E: [pulseaudio] droid-config.c: Failed to parse any configuration.
...

Indeed, line 78 of /vendor/etc/audio_policy_configuration.xml had an error, where a property was spelt like simplingRate instead of samplingRate. However, the "vendor" partition is read-only, so I couldn't change that file directly. Another option could have been creating a fixed copy of the file and place it with /system/etc/audio_policy_configuration.xml, but the "system" is also read-only (there are ways to modify these partitions, of course, but I couldn't find a clean way to do it from the device tree scripts. So I went for the bind-mount approach: I would ship the fixed file in some other directory of the file-system, and then modify the /etc/init/mount-android.conf file (this is the job that upstart executes before starting the Android LXC container) to bind-mount the file onto /vendor/etc/audio_policy_configuration.xml.

This worked, but my joy was short-lived: audio was coming up only once every 5 boots or so. I will not list here all the things I tried, as they were plenty of them; and more than once I went to sleep happy and convinced of having fixed the issue for good, until the next day the device booted without audio. It was clearly a timing issue occurring in the early boot, because one thing I clearly noticed very early on is that in those cases when the audio was booting, the following lines appeared in the kernel log:

[    7.130057] wcd937x_codec wcd937x-codec: msm_cdc_dt_parse_vreg_info: cdc-vdd-ldo-rxtx: vol=[1800000 1800000]uV, curr=[25000]uA, ond 0
[    7.130068] wcd937x_codec wcd937x-codec: msm_cdc_dt_parse_vreg_info: cdc-vddpx-1: vol=[1800000 1800000]uV, curr=[10000]uA, ond 0
[    7.130076] wcd937x_codec wcd937x-codec: msm_cdc_dt_parse_vreg_info: cdc-vdd-mic-bias: vol=[3296000 3296000]uV, curr=[25000]uA, ond 0
[    7.130084] wcd937x_codec wcd937x-codec: msm_cdc_dt_parse_vreg_info: cdc-vdd-buck: vol=[1800000 1800000]uV, curr=[650000]uA, ond 1
[    7.137759] wcd937x_codec wcd937x-codec: bound wcd937x-slave.1170224 (ops cleanup_module [wcd937x_slave_dlkm])
[    7.138065] wcd937x_codec wcd937x-codec: bound wcd937x-slave.1170223 (ops cleanup_module [wcd937x_slave_dlkm])

I started adding some printk to the kernel driver, and modified it slightly to register itself with the module_driver() macro instead of the simpler, but logless, module_platform_driver(). This showed that the driver was always loaded at about 7 seconds, but the platform_driver_register() method only called the driver's bind method (wcd937x_bind()) in those boots where audio was working.

After more debugging into platform_driver_register(), I stumbled upon the platform_match() function, added some debugging message in there to print the device name and the driver name, and observed how in those boots where audio was failing this function was called to find a driver for the wcd937x_codec device before the wcd937x_codec driver (provided by the wcd937x_dlmk module) was available. So, I tried adding wcd937x_dlmk to /etc/modules-load.d/modules.conf and this caused the driver to be loaded at about 3 seconds, and apparently fixed the audio issue. At least, till the time of writing this, I never had my phone boot without audio anymore.

Not all is fine with the audio, unfortunately: the mic records a background noise along with the actual sounds, and the recording volume is quite low. This also affects the call quality. On the other hand, the noise disappears when recording happens via the earphones. But I've yet to investigate this; I hope to give you some updates in part three.

0 0

The phone

I made myself a Christmas present and bought a Xiaomi Redmi Note 7 Pro, a dual-SIM phone from 2019 with 6GB of RAM and 128GB of flash storage. To be totally honest, I bought it by mistake: the phone I really wanted to buy is the Redmi Note 7 (without the "Pro"), because it's a modern phone that is working reasonable well with Ubuntu Touch. The online shop where I bought it from let me choose some options, including the RAM size, so I chose the maximum available (6GB) without being aware that this would mean that I would be buying the "Pro" device — the shop did not alter the item name, so I couldn't really know. Unfortunately, the two versions are two rather different beasts, powered by different SoC; both are produced by Qualcomm, so they are not that different, but it's enough to make the installation of Ubuntu Touch impossible.

But between the choice of retuning the phone to the shop and begin a new porting adventure, I stood firm and went for the latter. Hopefully I won't regret it (if everything goes bad, I can still use it with LineageOS, which runs perfectly on it).

Moreover, there already exist a port of Ubuntu Touch for this phone, which actually works reasonably well (I tried it briefly, and many things were working), but the author claims to be a novice and indeed did not follow the best git practices when working on the source code, so it's hard to understand what was changed and why. But if you are looking for a quick way to get Ubuntu Touch working on this phone, you are welcome to have a look at this Telegram channel.

What follows are the raw notes of my attempts. They are here so that search engines can index the error messages and the various logs, and hopefully help someone hitting similar errors on other devices to find his way out.

Getting Halium and the device source code

Installed the dependencies like in the first step. repo was not found in the Ubuntu 20.04 archives, but I had it installed anyway due to my work on a Yocto device.

Since my device has Android 9 on it, I went for Halium 9:

repo init -u git://github.com/Halium/android.git -b halium-9.0 --depth=1
repo sync -c -j 16

The official LineageOS repository for the Xiaomi Redmi Note 7 Pro is android_device_xiaomi_violet, but the page with the official build has been taken down (some DMCA violation, if you believe the forums) and no development has been happening since last year. A more active forum thread uses another repository which seems to be receiving more frequent updates, so I chose to base my port on that.

I actually tested that LineageOS image on my phone, and verified that all the hardware was working properly.

Initially, I created forks of the relevant repository under my own gitlab account, but then I though (especially looking at the Note 7 port) that creating a group just for this port would make people's life easier, because they wouldn't need to navigate through my 1000 personal projects to find what is relevant for this port. So, I created these forks:

• gitlab.com/ubuntu-touch-xiaomi-violet/android_device_xiaomi_violet
• gitlab.com/ubuntu-touch-xiaomi-violet/android_kernel_xiaomi_violet
• gitlab.com/ubuntu-touch-xiaomi-violet/android_vendor_xiaomi_violet

Next, created the halium/devices/manifests/xiaomi_violet.xml file with this content:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
    <!-- Remotes -->
    <remote name="ubuntu-touch-xiaomi-violet"
            fetch="https://gitlab.com/ubuntu-touch-xiaomi-violet"
            revision="halium-9.0"/>

    <!-- Device Tree -->
    <project path="device/xiaomi/violet"
             name="android_device_xiaomi_violet"
             remote="ubuntu-touch-xiaomi-violet" />

    <!-- Kernel -->
    <project path="kernel/xiaomi/violet"
             name="android_kernel_xiaomi_violet"
             remote="ubuntu-touch-xiaomi-violet" />

    <!-- Proprietary/Vendor blobs -->
    <project path="vendor/xiaomi/violet"
             name="android_vendor_xiaomi_violet"
             remote="ubuntu-touch-xiaomi-violet" />
</manifest>

Fetching all the sources mentioned in the manifest:

./halium/devices/setup violet

Full output:

*****************************************
I: Configuring for device xiaomi_violet
*****************************************
Fetching projects: 100% (393/393), done.
hardware/qcom/audio-caf/apq8084: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/msm8916: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/msm8952: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/msm8960: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/msm8974: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/msm8994: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/msm8996: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/msm8998: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/sdm845: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio-caf/sm8150: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/audio/default: Shared project LineageOS/android_hardware_qcom_audio found, disabling pruning.
hardware/qcom/display: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/apq8084: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/msm8916: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/msm8952: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/msm8960: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/msm8974: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/msm8994: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/msm8996: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/msm8998: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/sdm845: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/display-caf/sm8150: Shared project LineageOS/android_hardware_qcom_display found, disabling pruning.
hardware/qcom/media: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/apq8084: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/msm8916: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/msm8952: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/msm8960: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/msm8974: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/msm8994: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/msm8996: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/msm8998: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/sdm845: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/qcom/media-caf/sm8150: Shared project LineageOS/android_hardware_qcom_media found, disabling pruning.
hardware/ril: Shared project LineageOS/android_hardware_ril found, disabling pruning.
hardware/ril-caf: Shared project LineageOS/android_hardware_ril found, disabling pruning.
hardware/qcom/wlan: Shared project LineageOS/android_hardware_qcom_wlan found, disabling pruning.
hardware/qcom/wlan-caf: Shared project LineageOS/android_hardware_qcom_wlan found, disabling pruning.
hardware/qcom/bt: Shared project LineageOS/android_hardware_qcom_bt found, disabling pruning.
hardware/qcom/bt-caf: Shared project LineageOS/android_hardware_qcom_bt found, disabling pruning.
Updating files: 100% (67031/67031), done.nel/testsUpdating files:  36% (24663/67031)
lineage/scripts/: discarding 1 commits
Updating files: 100% (1406/1406), done.ineageOS/android_vendor_qcom_opensource_thermal-engineUpdating files:  47% (666/1406)
Checking out projects: 100% (392/392), done.
*******************************************
I: Refreshing device vendor repository: device/xiaomi/violet
I: Processing proprietary blob file: device/xiaomi/violet/./proprietary-files.txt
I: Processing fstab file: device/xiaomi/violet/./rootdir/etc/fstab.qcom
I: Removing components relying on SettingsLib from: device/xiaomi/violet
*******************************************

Starting the build

Setting up the environment:

$ source build/envsetup.sh
including device/xiaomi/violet/vendorsetup.sh
including vendor/lineage/vendorsetup.sh
$

Running the breakfast command:

$ breakfast violet
including vendor/lineage/vendorsetup.sh
Trying dependencies-only mode on a non-existing device tree?

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=9
LINEAGE_VERSION=16.0-20210109-UNOFFICIAL-violet
TARGET_PRODUCT=lineage_violet
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm64
TARGET_ARCH_VARIANT=armv8-a
TARGET_CPU_VARIANT=kryo300
TARGET_2ND_ARCH=arm
TARGET_2ND_ARCH_VARIANT=armv8-a
TARGET_2ND_CPU_VARIANT=cortex-a75
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-5.4.0-58-generic-x86_64-Ubuntu-20.04.1-LTS
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=PQ3A.190801.002
OUT_DIR=/home/mardy/projects/port/halium/out
PRODUCT_SOONG_NAMESPACES= hardware/qcom/audio-caf/sm8150 hardware/qcom/display-caf/sm8150 hardware/qcom/media-caf/sm8150
============================================

Building the kernel

The configuration needs to be adapted for Halium. Locating the kernel config:

$ grep "TARGET_KERNEL_CONFIG" device/xiaomi/violet/BoardConfig.mk 
TARGET_KERNEL_CONFIG := vendor/violet-perf_defconfig
$

Getting the Mer checker tool and running it:

git clone https://github.com/mer-hybris/mer-kernel-check
cd mer-kernel-check
./mer_verify_kernel_config ../kernel/xiaomi/violet/arch/arm64/configs/vendor/violet-perf_defconfig

Prints lots of warnings, starting with:

WARNING: kernel version missing, some reports maybe misleading

To help the tool, we need to let him know the kernel version. It can be seen at the beginning of the kernel Makefile, located in ../kernel/xiaomi/violet/Makefile; in my case it was

VERSION = 4
PATCHLEVEL = 14
SUBLEVEL = 83
EXTRAVERSION =

So I edited the configuration file ../kernel/xiaomi/violet/arch/arm64/configs/vendor/violet-perf_defconfig and added this line at the beginning:

# Version 4.14.83

then ran the checker tool again. This time the output was a long list of kernel options that needed to be fixed, but as I went asking for some explanation in the Telegram channel for Ubuntu Touch porters, I was told that I could/should skip this test and instead use the check-kernel-config tool from Halium. I downloaded it, made it executable (chmod +x check-kernel-config) and ran it:

./check-kernel-config kernel/xiaomi/violet/arch/arm64/configs/vendor/violet-perf_defconfig
[...lots of red and green lines...]
Config file checked, found 288 errors that I did not fix.

I ran it again with the -w option, and it reportedly fixed 287 errors. Weird, does that mean that an error was still left? I ran the tool again (without -w), and it reported 2 errors. Ran it once more in write mode, and if fixed them. So, one might need to run it twice.

Next, added the line

BOARD_KERNEL_CMDLINE += console=tty0

in device/xiaomi/violet/BoardConfig.mk. One more thing that needs to be done before starting the build is fixing the mount points, so I opened device/xiaomi/violet/rootdir/etc/fstab.qcom and changed the type of the userdata partition from f2fs to ext4. There were no lines with the context option, so that was the only change I needed to do.

At this point, while browsing throught the documentation, I found a link to this page which contains some notes on Halium 9 porting, which are substantially different from the official porting guide in halium.org (which I was already told in Telegram to be obsolete in several points).

So, following the instructions from this new link I ran

hybris-patches/apply-patches.sh --mb

which completed successfully.

Then, continuing following the points from this page, I edited device/xiaomi/violet/lineage_violet.mk, commented out the lines

$(call inherit-product, $(SRC_TARGET_DIR)/product/full_base_telephony.mk)
# ...
$(call inherit-product, vendor/lineage/config/common_full_phone.mk)

and replaced the first one with a similar line pointing to halium.mk. For the record, a find revealed that the SRC_TARGET_DIR variable in my case was build/make/target/. It contained also the halium.mk file, which was created by the hybris patches before. As for removing the Java dependencies, I cound't find any modules similar to those listed in this commit in any of the makefiles in my source tree, so I just started the build:

source build/envsetup.sh && breakfast violet
make halium-boot

This failed the first time with the compiler being killed (out of memory, most likely), but it succeeded on the second run. There was a suspicious warning, though:

drivers/input/touchscreen/Kconfig:1290:warning: multi-line strings not supported

And indeed my kernel/xiaomi/violet/drivers/input/touchscreen/Kconfig had this line:

source "drivers/input/touchscreen/ft8719_touch_f7b/Kconfig

(notice the unterminated string quote). I don't know if this had any impact on the build, but just to be on the safe side I added the missing quote and rebuilt.

Building the system image

Running

make systemimage

failed pretty soon:

ninja: error: '/home/mardy/projects/port/halium/out/soong/host/linux-x86/framework/turbine.jar', needed by '/home/mardy/projects/port/halium/out/soong/.intermediates/libcore/core-oj/android_common/turbine/core-oj.jar', missing and no known rule to make it

The error is due to all the Java-related stuff that I should have disabled but couldn't find. So, I tried to have a look at the changes made on another xiaomi device (lavender, the Redmi note 7, which might not be that different, I thought) and started editing device/xiaomi/violet/device.mk and removing a couple of Android packages. Eventually the build proceeded, just to stop at a python error:

  File "build/make/tools/check_radio_versions.py", line 56
    print "*** Error opening \"%s.sha1\"; can't verify %s" % (fn, key)
          ^
SyntaxError: invalid syntax

Yes, it's the python3 vs python2 issue, since in my system python is python version 3. In order to fix it, I created a virtual environment:

virtualenv --python 2.7 ../python27  # adjust the path to your prefs
source ../python27/bin/activate

Remember that the second line must be run every time you'll need to setup the Halium build environment (that is, every time you run breakfast).

The build then proceeded for several minutes, until it failed due to some unresolved symbols:

prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: error: /home/mardy/projects/port/halium/out/target/product/violet/obj/STATIC_LIBRARIES/lib_driver_cmd_qcwcn_intermediates/lib_driver_cmd_qcwcn.a: member at 7694 is not an ELF object
external/wpa_supplicant_8/hostapd/src/drivers/driver_nl80211.c:7936: error: undefined reference to 'wpa_driver_set_p2p_ps'
/home/mardy/projects/port/halium/out/target/product/violet/obj/EXECUTABLES/hostapd_intermediates/src/drivers/driver_nl80211.o:driver_nl80211.c:wpa_driver_nl80211_ops: error: undefined reference to 'wpa_driver_set_ap_wps_p2p_ie'
/home/mardy/projects/port/halium/out/target/product/violet/obj/EXECUTABLES/hostapd_intermediates/src/drivers/driver_nl80211.o:driver_nl80211.c:wpa_driver_nl80211_ops: error: undefined reference to 'wpa_driver_get_p2p_noa'
/home/mardy/projects/port/halium/out/target/product/violet/obj/EXECUTABLES/hostapd_intermediates/src/drivers/driver_nl80211.o:driver_nl80211.c:wpa_driver_nl80211_ops: error: undefined reference to 'wpa_driver_set_p2p_noa'
/home/mardy/projects/port/halium/out/target/product/violet/obj/EXECUTABLES/hostapd_intermediates/src/drivers/driver_nl80211.o:driver_nl80211.c:wpa_driver_nl80211_ops: error: undefined reference to 'wpa_driver_nl80211_driver_cmd'

As people told me in the Telegram channel, this driver is not used since "our wpa_supplicant talks to kernel directly". OK, so I simply disabled the driver, copying again from the lavender Halium changes: commented out the BOARD_WLAN_DEVICE := qcwcn line (and all lines referring this variable) from device/xiaomi/violet/BoardConfig.mk and ran make systemimage again. This time, surprisingly, it all worked.

Try it out

I first tried to flash the kernel only. I rebooted into fastboot, and on my PC ran this:

cout
fastboot flash boot halium-boot.img

I then rebooted my phone, but after showing the boot logo for a few seconds it would jump to the fastboot screen. Indeed, flashing the previous kernel would restore the normal boot, so there had to be something wrong with my own kernel.

While looking at what the problem could be, I noticed that in the lavender port the author did not modify the lineageos kernel config file in place, but instead created a new one and changed the BoardConfig.mk file to point to his new copy. Since it sounded like a good idea, I did the same and created kernel/xiaomi/violet/arch/arm64/configs/vendor/violet_halium_defconfig for the Halium changes. And then the line in the board config file became

TARGET_KERNEL_CONFIG := vendor/violet_halium_defconfig

I then continued investigating the boot issue, and I was told that it might have been due to an Android option, skip_initramfs, which is set by the bootloader and causes our Halium boot to fail. The fix is to just disable this option in the kernel, by editing init/initramfs.c and change the skip_initramfs_param function to always set the do_skip_initramfs variable to 0, rather than to 1. After doing this, the boot proceeded to show the Ubuntu splash screen with the five dots being lit, but it didn't proceed from there.

Setting up the udev rules

Even in this state, the device was detected by my host PC and these lines appeared in the system log:

kernel: usb 1-3: new high-speed USB device number 26 using xhci_hcd
kernel: usb 1-3: New USB device found, idVendor=0fce, idProduct=7169, bcdDevice= 4.14
kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 1-3: Product: Unknown
kernel: usb 1-3: Manufacturer: GNU/Linux Device
kernel: usb 1-3: SerialNumber: GNU/Linux Device on usb0 10.15.19.82

Indeed, I guess the reason I could do this without even flashing my systemimage is because I had first flashed another UT system image from another porter. I'm not sure if I'd had the same results with my own image. Anyway, the USB networking was there, so I connected and ran the following commands to generate the udev rules:

ssh phablet@10.15.19.82
# used 0000 as password
sudo -i
# same password again
cd /home/phablet
DEVICE=violet
cat /var/lib/lxc/android/rootfs/ueventd*.rc /vendor/ueventd*.rc \
        | grep ^/dev \
        | sed -e 's/^\/dev\///' \
        | awk '{printf "ACTION==\"add\", KERNEL==\"%s\", OWNER=\"%s\", GROUP=\"%s\", MODE=\"%s\"\n",$1,$3,$4,$2}' \
        | sed -e 's/\r//' \
        >70-$DEVICE.rules

I then copied (with scp) this file to my host PC, and I moved it to device/xiaomi/violet/ubuntu/70-violet.rules (I had to create the ubuntu directory first). Then I edited the device/xiaomi/violet/device.mk file and added these lines at the end:

### Ubuntu Touch ###
PRODUCT_COPY_FILES += \
    $(LOCAL_PATH)/ubuntu/70-violet.rules:system/halium/lib/udev/rules.d/70-android.rules
### End Ubuntu Touch ###

It was now time to try my own system image. I rebooted my device into TWRP, I cloned the halium-install repository into my halium build dir, downloaded a rootfs for Halium9, and ran

./halium-install/halium-install -p ut \
    ~/Downloads/ubuntu-touch-android9-arm64.tar.gz \
    out/target/product/violet/system.img

The first time this failed because the simg2img tool was not installed. The second time it proceeded to create the image, asked me for a password for the phablet user (gave "0000") and pushed the image onto the device, into the /data/ partition. I then rebooted.

My first Ubuntu Touch image

Upon reboot, the usual splash screen appeared, followed by several seconds of black screen. It definitely didn't look right, but at least it proved that something had been flashed. After some more seconds, to my big surprise, the Ubuntu boot screen appeared, just with a smaller logo than how it used to be before, which also confimed that my system image was being used — in fact, I did not adjust the GRID_UNIT_PX variable before. Since this was an easy fix, I chose to focus on that, rather than fix the boot issues (indeed, my device did not move on from the Ubuntu boot screen). SSH was working.

I took the scaling.conf file from the lavender changes, put it in device/xiaomi/violet/ubuntu/ and added this line in the PRODUCT_COPY_FILES in device.mk:

$(LOCAL_PATH)/ubuntu/scaling.conf:system/halium/etc/ubuntu-touch-session.d/android.conf

I initially used system/ubuntu/etc/... as the target destination for the config file, like in the lavender commit, but this didn't work out for me. Then I changed the path to start with system/halium/, like it's mentioned in the ubports documentation, but it apparently had no effect either.

After a couple of days spent trying to understand why my files were not appearing under /etc, it turned out that the device was not using my system image at all: with halium-install I had my image installed in /userdata/system.img, while the correct path for Halium 9 devices is /userdata/android-rootfs.img. I was told that the option -s of halium-install would do the trick. Instead of re-running the script, I took the shortcut of renaming /userdata/system.img to /userdata/android-rootfs.img and after rebooting I could see that the Ubuntu logo was displayed at the correct size. And indeed my system image was being used.

So I started to debug why unity8 didn't start. The logs terminated with this line:

terminate called after throwing an instance of 'std::runtime_error'
  what():  org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
initctl: Event failed

It means, that unity8 did not handle correctly the situation where another D-Bus service crashed while handing a call from unity8. The problem now was how to figure out which service it was. I ran dbus-monitor and restarted unity8 (initctl start unity8), then examined the dbus logs; I saw the point where unity8 got disconnected from the bus, but before that point I didn't find any failed D-Bus calls. So it had to be the system bus. I did exactly the same steps, just this time after running dbus-monitor --system as root, I found the place where unity8 got disconnected, and found this D-bus error shortly before that:

method call time=1605676421.968667 sender=:1.306 -> destination=com.ubuntu.biometryd.Service serial=3 path=/default_device; interface=com.ubuntu.biometryd.Device; member=Identifier
method return time=1605676421.970222 sender=:1.283 -> destination=:1.306 serial=4 reply_serial=3
   object path "/default_device/identifier"
...
method call time=1605676421.974218 sender=:1.283 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetConnectionAppArmorSecurityContext
   string ":1.306"
error time=1605676421.974278 sender=org.freedesktop.DBus -> destination=:1.283 error_name=org.freedesktop.DBus.Error.AppArmorSecurityContextUnknown reply_serial=6
   string "Could not determine security context for ':1.306'"
...
signal time=1605676421.989074 sender=org.freedesktop.DBus -> destination=:1.283 serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string "com.ubuntu.biometryd.Service"
...
error time=1605676421.989302 sender=org.freedesktop.DBus -> destination=:1.306 error_name=org.freedesktop.DBus.Error.NoReply reply_serial=4
   string "Message recipient disconnected from message bus without replying"

So, it looks like unity8 (:1.306) made a request to biometryd, who asked the D-Bus daemon what was the AppArmor label of the caller, but since I didn't backport the D-Bus mediation patches for AppArmor, the label could not be resolved. biometryd decided to crash instead of properly handling the error, and so did unity8.

So I backported the AppArmor patches. I took them from the Canonical kernel repo, but they did not apply cleanly because they are meant to be applied on top of a pristine 4.14 branch, whereas the Android kernel had already some AppArmor security fixes backported from later releases. So I set and quickly inspected the contents of each patch, and found out that a couple of them had already been applied, and the last patch had to be applied as the first (yeah, it's hard to explain, but it all depends on other patches that Android has backported from newer kernels). Anyway, after rebuilding the kernel and reflashing it, my phone could finally boot to unity8!

Conclusion (of the first episode)

The actual porting, as I've been told, starts here. What has been documented here are only the very first steps of the bring-up; what awaits me now is to make all the hardware subsystems work properly, and this, according to people more experienced in porting, is the harder part.

So far, very few things work, to the point that it's faster to me to list the things that do work; it's safe to assume that all what is not listed here is not working:

• Mir, with graphics and input: Unity8 starts and is usable
• Camera: can take photos; video recording start but an error appears when the stop button is pressed
• Flashlight
• Fingerprint reader: surprisingly, this worked out of the box
• Screen brightness (though it can be changed only manually)

For all the rest, please keep an eye on this blog: I'll write, when I make some progress!

0 0

You know that I'm not an early adopter. That's why it was only a couple of weeks ago when I decided to give Qbs a try, by using the good old Mappero (and its spin-off, Mappero Geotagger) as a test bench. Yes, I know that the Qt company is not going to maintain Qbs anymore in the future, but the little I knew about Qbs was enough to convince me that it's a project worth supporting. So, better late than never -- and hopefully the community (me included) will do a good job in keeping Qbs thriving.

Having Mappero build with Qbs was the simplest thing ever. The only issue I met was in building the unit tests, because I'm used to set the rpath on test executables in order to make it easy to run them uninstalled, and with qmake I achieved that with this:

QMAKE_RPATHDIR = $${QMAKE_LIBDIR}

In turns out that with Qbs you can do it in almost the same way, but for some reason I couldn't figure it out and I even reported a bug to which I got some nice suggestions, before eventually settling on this:

import qbs 1.0

Test {
    name: "path-test"

    files: [
        "path-test.cpp",
        "path-test.h",
        "paths.qrc",
    ]

    Depends { name: "Mappero" }
    cpp.rpaths: cpp.libraryPaths    // <-- this does the trick!
}

It's surprisingly similar to how it's done in qmake, so it's not clear even to me why I didn't guess that immediately. Anyway, that was literally my only problem, and you can see the whole set of Qbs files I wrote by having a look at this commit.

Given how easy the migration was, I thought I should also try to add a code coverage report; that's not something I had in my qmake build either, but it's something I really want to have in all my newer projects.

Teaching Qbs to make a code coverage report

Unfortunately, my search for examples on how to have Qbs prepare a coverage report was mostly insuccessful, but thanks to some amazing help from Christian in the #qbs IRC channel, this was not hard to achieve. So, I hope to be of some help myself too, by sharing how this works.

First of all, it must be said that Qbs doesn't know anything about code coverage, at all. However, it's possible (and often easy) to extend Qbs by adding your own Product with its own set of build rules, so here's the CoverageReport item for Mappero (though, it should be general enough to be reusable in your own project):

import qbs

Product {
    name: "coverage"

    property string outputDirectory: "coverage-html"
    property stringList extractPatterns: []

    builtByDefault: false
    files: ["**"]
    type: ["coverage.html"]

    Depends { productTypes: ["autotest-result"] }

    Rule {
        multiplex: true
        explicitlyDependsOnFromDependencies: ["autotest-result"]
        outputFileTags: "coverage.html"
        requiresInputs: false
        prepare: {
            var commands = []
            var captureCmd = new Command("lcov", [
                "--directory", project.sourceDirectory,
                "--capture",
                "--output-file", "coverage.info",
                "--no-checksum",
                "--compat-libtool",
            ]);
            captureCmd.description = "Collecting coverage data";
            captureCmd.highlight = "coverage";
            captureCmd.silent = false;
            commands.push(captureCmd);

            var extractArgs = []
            for (var i = 0; i < product.extractPatterns.length; i++) {
                extractArgs.push("--extract");
                extractArgs.push("coverage.info");
                extractArgs.push(product.extractPatterns[i]);
            }
            if (product.extractPatterns.length > 0) {
                extractArgs.push("-o");
                extractArgs.push("coverage.info");
                var extractCmd = new Command("lcov", extractArgs);
                extractCmd.description = "Extracting coverage data";
                extractCmd.highlight = "coverage";
                extractCmd.silent = false;
                commands.push(extractCmd);
            }

            var filterCmd = new Command("lcov", [
                "--remove", "coverage.info", 'moc_*.cpp',
                "--remove", "coverage.info", 'qrc_*.cpp',
                "--remove", "coverage.info", '*/tests/*',
                "-o", "coverage.info",
            ]);
            filterCmd.description = "Filtering coverage data";
            filterCmd.highlight = "coverage";
            filterCmd.silent = false;
            commands.push(filterCmd);

            var genhtmlCmd = new Command("genhtml", [
                "--prefix", project.sourceDirectory,
                "--output-directory", product.outputDirectory,
                "--title", "Code coverage",
                "--legend",
                "--show-details",
                "coverage.info",
            ]);
            genhtmlCmd.description = "Generate HTML coverage report";
            genhtmlCmd.highlight = "coverage";
            genhtmlCmd.silent = false;
            commands.push(genhtmlCmd);

            return commands;
        }
    }
}

The most important thing here are the references to the autotest-result tag: this is the tag used by the AutotestRunner Qbs item, which is responsible for running the unit tests. Referencing its product's tag in the Depends item and in the explicitlyDependsOnFromDependencies properties ensures that "building" our product will cause the unit tests to run. Other needed bits are the requiresInputs: false property, which means that our rule doesn't have any required inputs, and the builtByDefault: false property, which says that our coverage report should not be generated when just typing qbs. Instead, to run the tests and get the code coverage report one will have to request it explicitly, by typing

qbs -p coverage

The prepare property of the Rule is where the commands to generate the code coverage report are defined. Here we can use the Command item to invoke external programs, and we return a list of such items, so that the commands will be executed in sequence. Note that here I'm using lcov and expecting to find the coverage data produced by gcov, so this is probably not portable outside of Linux/gcc.

Using the CoverageReport item is quite easy: you just need to declare it, and specify which paths contain the coverage data that you are interested in (otherwise, lcov will collect data from all object files that it find under the build directory, which might not be what you desire):

    CoverageReport {
        condition: project.enableCoverage
        extractPatterns: [ '*/src/*.cpp', '*/lib/*.cpp' ]
    }

There's little more than that to be done. Of course, you need to find a way to pass the --coverage option to gcc when building your products, and for this I created a small buildconfig module in qbs/modules/buildconfig/BuildConfig.qbs which I depend on in all products which I wish to build with coverage enabled:

import qbs

Module {
    cpp.cxxFlags: project.enableCoverage ? ["--coverage"] : undefined
    cpp.dynamicLibraries: project.enableCoverage ? ["gcov"] : undefined

    Depends { name: "cpp" }
}

If all this looks scary, you should probably have a look at the diff which shows how I added code coverage reporting to qbs: hopefully you'll find that it's not that complex, after all.

I hope that Qbs users will find this interesting, and possibly improving my setup. Ideally we should try to get something like this part of Qbs itself, but portability outside of Linux / gcc is going to be an issue.

1 0

At the beginning of this month I participated to the foss-north conference, in Gothenburg, and took the stage to give a short presentation of the blockchain technology. Given that my talk was somehow critical of the blockchain (or rather, of the projects using it without due reason) I was prepared to receive a wave of negative remarks, assuming that all the hype surrounding this technology would have infected a good part of my audience as well. I was therefore positively surprised when several people came to me afterwords to express their appreciation for my speech, appreciation that now makes me confident enough to share the video of the presentation here too:

I want to publicly thank Johan Thelin and all the other foss-north staff and volunteers who organized such a successful conference. They also managed to get the video recordings out in a surprisingly short time. Indeed, the above video is taken from the foss-north YouTube channel, which I recommend you to visit as there were a lot of good talks at the conference; the topics were so varied, that I'm sure you'll find at least a couple of talks of your interest.

1 0

Last November I was invited to talk at the LinuxPiter conference. I held a presentation of the Ubports project, to which I still contribute in my little spare time.

The video recording from the conference has finally been published:

(there's also a version in Russian)

There was not a big audience, to be honest, but those that were there expressed a lot of interest in the project.

1 0

• written in C
• POSIX (tested in Linux and FreeBSD)
• small (~850 LOC)
• well commented (~400 lines)
• good test coverage
• zerocopy
• lockless
• one writer, many readers
• data is written and read in chunks of arbitrary size
• a data chunk becomes visible to the readers as soon as the writer commits it
• data chunks can have an expiration time
• data chunks can be obsoleted by a newer copy
• garbage collector
• no file descriptors are permanently kept open
• no change notification

• to implement a data stream: the writer fills the shared memory area with short-lived data chunks
• sharing changeable blocks of data

1 0

Of course you are not forced to have Oculo manage your wallpapers. :-) Oculo can still render the web content into a homescreen widget, and you can run multiple instances of it, in different modes. Also, you can have Oculo render only some of your homescreen views, while keeping the rest static.

Version 0.9 of Oculo is in the extras-testing repository, and you can directly download it from here. Be warned that I just tested the widget for a couple of minutes, so anything bad can happen. :-)

12 0

The mandatory screenshot. Three instances of Oculo: Flickr! explore, Google local news, Yahoo! finance.

As I'm writing this, Oculo 0.7 is in the Maemo extras-testing repository; I'm using it without problems in my N900, but it's still rather buggy, so if you try and find some problems, don't hesitate to report them. Unfortunately, it is already known that Oculo will not be visible if you are running the community SSU; this is apparently a problem with the CSSU and Qt home widgets which I'm investigating. Also, since the configuration procedure might not be as intuitive as it could be, I've created a video which shows how to configure it:

History and technical aspects

The idea of developing Oculo (which means “eye” in interlingua) came to me a few months ago, when I noticed that Radek, a colleague of mine, was checking the daily menu of our canteen in the intranet pages. I ironically suggested him that he should write a maemo home widget showing the daily menu, so he could have it always visible on his phone. The fact that I considered “silly” the idea of writing a homescreen widget just for that goal suddenly brought up the idea of Oculo: giving the user the possibility to put in his homescreen whatever web content he desires.

Using Qt and QWebKit to render the web page contents into an image was unbelievably simple, and boosted my motivation in developing the widget. In a couple of days I already got something that was usable to me; but as Mappero users know, my usability standards are quite low :-), and this time I realized that I couldn't just publish Oculo in that state. So I went on developing the configuration dialog, tried hard to improve the graphical appearance of the widget (which still looks bad, but you haven't seen how it was before :-p) and solve some performance issues. The biggest of which was the memory consumption of the widget due to keeping QWebKit loaded in memory; this has now been solved by moving the configuration phase and the web content retrieval/rendering into a separate process, which is running only when needed. The homescreen widget itself is just a container for the image.

Future developments

A quick roadmap of what should be coming for Oculo:

• Minimum interval between updates will be configurable (this is trivial and will be coming very soon)
• Speed improvements: try not to load external content which will not be rendered
• Share configurations between users; let users upload/download their configuration to a central server — this will make the configuration much easier
• Port Oculo to MeeGo (to be investigated)
• Port Oculo to Linux desktops
• If Qt on Android can be used to develop home screen widget, an Android port might also be possible.

That's all for now! Go and try Oculo out, and let me know your impressions. :-)

13 0

No matter how wrong my interpretation might be, let's try to collect a few facts:

• MeeGo is ready, it's not an R&D project: a MeeGo phone will be released
• Nokia's primary platform for the middle/long term is Windows Mobile
• Meego will become, within Nokia, an R&D project at best

I feel confused and fooled. Business logics are floating several metres above my head, and I cannot understand what's the point of saying that MeeGo will be an R&D project when it's not. To me, it's like taking a teenager and trying to squeeze him into a baby's cradle. Either you kill him more or less explicitly, or you take him out, let him grow and give him a chance to be a hero. We are going to have the best phone in the market this year. It might not be perfect, as the N900 clearly wasn't, but all the premises for a brilliant future are there. And people will love it, as they loved the N900 despite it being far away from the quality standards we aspired to achieve and despite a zero-digits investment on marketing. Maemo won, against all odds.

One thing is clear: Nokia is not committed to Linux and the platform for the future Nokia devices is not going to be Linux-based, at least in the middle term. Because if it were, I can't see a reason why it couldn't be MeeGo.

If I try to imagine my future career in Nokia, I see myself either working on applications or R&D projects on top of Windows Mobile, or trying to squeeze the teenager into the cradle, and maybe put him into the refrigerator and periodically check that he doesn't die, because hey, he's our far future hope.
So, what do I have against Windows Mobile? Simple: it's closed source software. And it doesn't matter if the software I develop is open-source; on the contrary, if I had to choose between developing open-source software on top of a closed platform and developing closed-source software on top of an open-source platform, I'd much rather go for the second option: because with the first one I'd still be using and promoting a closed platform, and unless you are developing a cross-platform application or framework, you'd be doing very little good to the open source world.

Summing up. I really wish that Nokia took one step back and revised their plan. Not because I ask it of course, but because the loyal customers, the developers and the investors are asking it. And give a clear statement on what is the future of MeeGo, Linux and open-source within Nokia. Meanwhile, my CV has been updated and has appeared on this blog's navigation menu for anyone to read. Companies committed to Linux are welcome to contact me for proposing a job or even a shorter term collaboration. It would be wonderful if I was given a chance to continue working on MeeGo, work on some cool ideas, work to introduce the Accounts & SingleSignOn framework to more Linux distributions and open-source OSes. Or actually, anything where I would be given a chance to develop on top of open-source software.
Proposals from Nokia are welcome as well.

Note: in this blog post I'm talking only about MeeGo because it's what's affecting me most, and I wanted to keep the post to the point. It doesn't mean that I don't care about Symbian's future and Qt deployment.

38 0

It sometimes happens (especially to people living in Italy) that the address you need exists in different cities. “Via Roma”, for instance, is one very common street name in Italy, so if you are searching for it in Google Maps web interface you won't get a route, but instead you'll get a list of possible matches. And so far, in such a situation Mappero would have spit out the infamous “Invalid source or destination.” error message.
In today's release the situation is improved, because when we get a disambiguation request from Google Maps, Mappero shows the screen above and lets you pick your destination. This should hopefully save you some time when typing addresses.

I still have a few unclear points about Google Maps behaviour, because sometimes the reply is different from what we get via web, and it seems that it doesn't always honour our request for local results only. So, if someone is familiar with Google Maps parameters and knows how to get the destination address resolved using a local search, please let me know and as a reward I'll append your name to all street names returned by Mappero. ;-)

By the way, the main reason for releasing this today was that this version also fixes the problem when libmappero doesn't get automatically upgraded along with Mappero. Also, the fact of having received a huge donation stimulated me to do something in return. :-)

Oh! I hope that now you won't be expecting a new release every day! But in case you do, here is how you can make it happen.

13 0