Paul Kocialkowski's coding blog

Free software, programming and stuff

gps

Galaxy S2 Replicant port status update

Written by Paul Kocialkowski - 04 february 2013 - 2 comments

Quite some time ago, I was given the opportunity to receive a crowd-funded Galaxy S2 phone. Even though I was very thankful for it, I couldn't really focus on it at first since I had to handle other things on various other devices I was working on. It left me somehow sad as I felt that it was my duty to add proper Replicant support for it. Today, I'm proud to announce that the biggest part of the work to support it is over.

The modem (XMM6260)

At first, we had to add support for the modem, an XMM 6260 modem with a custom Samsung firmware. The modem protocol is what we call Samsung IPC, the very same as the one used in the Nexus S or Galaxy S. Our lower-layer library to handle it is libsamsung-ipc, that is shared between Replicant and SHR. So We had to add support for XMM6260 in libsamsung-ipc, along with Galaxy S2-specific bits. Thoughtfully, we designed the upper layer, Samsung-RIL (that is specific to Replicant) to work with libsamsung-ipc regardless of the device it's running on. Nowadays, the modem support is complete and we have working calls, messages and data. Anyway, modem features support is up to Samsung-RIL, so it's not Galaxy S2-specific.

The Audio CODEC (Yamaha MC1N2)

After doing a break in Galaxy S2 development, I finally got back to it, and started the 4.0 Replicant version for the occasion. Since the audio module was non-free in CyanogenMod, it was one of the key components to add support for. (What good is a phone if you can't get any sound out of it?) So after digging a little in the kernel code, it turned out that the Audio CODEC had an ALSA interface driver. That means PCM In/Out interfaces as well as Mixer controls. Only problem was that I still couldn't get any sound out of it using the TinyALSA test utils. After doing a bit of research, I found out about the /dev/snd/hwC0D0 node, that was implementing hardware-specific controls (via ioctl). After adding debug prints to it and with the help of some CyanogenMod developers, I was able to reimplement it on my Yamaha-MC1N2-Audio library. The ALSA part was done with a 4.0 update (call it a complete rewrite) of my TinyALSA-Audio library. The combination of the two made it possible to have sound with Replicant (including during calls). It is even used by CyanogenMod since version 10.1!

The sensors (K3DH accelerometer)

With modem and audio support, the Galaxy S2 was made usable as a phone. Thanks to the free hwcomposer module, it's very fast too, so I decided to use it as a main phone for a time, and frankly quite enjoyed the ride. The sensors were also relying on a non-free library, the one called libakm: AKM is the compass manufacturer. Nonetheless, it includes the bits to properly handle the K3DH accelerometer chip too. The situation is quite similar to the Nexus S sensors, and I was able to figure out the accelerometer part back then (it was a KR3DH) and implemented it in the libakm_free library. Since it was quite easy for Nexus S (libakm was just a passthrough), I gave it a try on the Galaxy S2. After tracing the K3DH kernel driver, I figured that the values returned by libakm were just the result of linear functions applied to the data returned by the kernel. I renamed libakm_free to Samsung-Sensors and added support for the K3DH there.

The cameras (M5MO/S5K5BAFX)

Galaxy S2 Camera

Galaxy S2 support was then already pretty decent, and I was kind of proud of myself. Though, it take a look at the Galaxy S2 characteristics, you'll see that one of its key features is the 8MP camera it embeds. And sadly, there was no usable camera module around. Though, it appeared to have a V4L2 driver, which is pretty standard and easy to implement. However, I feared that I'd have to face the same situation as audio: standard interface but only usable with a non-trivial interface aside. Once again, I traced the kernel driver and started implementing, step by step. After a couple weeks of work (I wrote the implementation from scratch and obviously couldn't spend time on it everyday), it appeared that the original non-free camera module was doing a lot of unnecessary output/overlay operations. So I decided to cut out the crap and get to the essential, that is only using the capture V4L2 interface. This comes with some issues such as the inability to resize/crop the output buffer, but I think I found acceptable workarounds for that. In the end, my camera module turned out to work quite well and is now fully-featured (except EXIF that is currently broken, but it's such a pain in the ass that I don't really want to get into it and fix things). I pushed the code on the Galaxy S2 device tree as well as on my personal Exynos Camera git repo.

The future?

Now the Galaxy S2 is supported as well as the Nexus S in Replicant and the missing (and doable) parts left are mainly GPS and compass. The compass is an AKM8975 chip. Some code was released by AKM for this chipset and even though my first attempts to make it work failed, I guess there is a way to have it working properly. I didn't renew my attempts since this is quite a detail and there is probably more important things to work on at the moment. That's for instance the GPS: it's a GSD4t chip, the very same as the Galaxy Nexus. It needs a firmware upload and uses a SiRF-derived protocol that does not seem to be documented anywhere. I hope we'll be able to figure it out somehow: it would be very nice to have GPS support on these two devices!

Contributing to OpenStreetMap part 2: Gathering data on the field

Written by Paul Kocialkowski - 30 december 2012 - no comments

I could keep writing a lot about the ideas behind the project, my personal motivation and such but well, OpenStreetMap is one of the rare projects I'm contributing to that actually require people to get out and see things for themselves ! So that's very good for us hackers that are used to do our work behind a screen: for once, we're required to get some fresh air. That has been a good opportunity for me to discover more of the city where I live, do some sports by the way and discover many relaxing places in a natural environment.

Bike

From the moment I started mapping, I always used a bike to move around town. That's probably the best way to catch every detail surrounding your ride, making it easy to stop at any moment and any place. I've done mapping on my feet a couple time too, it's good when there is a high-density of POI (Points Of Interest), like in the town centre. If this is not the case where you live, you are most likely going to waste a lot of valuable time. On the other hand, this can be a fun way to spend some hours to kill in the middle of the day.

The first device I used to do mapping was the Neo FreeRunner and its embedded GPS. I also got an external antenna to improve the reliability of the traces. On the software side, I was most of the time using Hackable:1 and TangoGPS but at some point switched to SHR with FoxtrotGPS. That was pretty nice to use, except that the keyboard with very small and required me to carry a pen. I attached the FreeRunner to my bike using cable ties though I had to drive very carefully to avoid damaging the phone.

Walking paper

Carrying a sheet of paper and a pen can also turn out to be very useful to draw a quick sketch of the ways and their names. When possible, printing walking papers (black and white is fine) with the already mapped OSM informations helps a lot too. I'm not a regular user of these methods but from time to time it helps, especially when there is not a lot of informations already available on OSM. Another kind of complementary mapping technique that I used from time to time is voice recording: this permits to be very precise in the description. These techniques are used best along with regular GPS tracking.

Tablet

As soon as all the streets were properly tagged, I focused on adding particular POI such as stores, bus stops, public buildings, etc. Thanks to the Cadastre, we have the detail of every building available in OSM, so we can precisely place POI without the need of GPS traces. The FreeRunner remains relevant for this task but just as well as other devices. At some point, I decided to switch to Android devices to map (with the OsmAnd app, that is free software). Since most of these devices come with a camera, it also permits to take pictures of the place quickly while mapping. A phone is fine for that, but the best I've found is a tablet with a large screen: you can place the POI precisely that way and enjoy the large keyboard. OSM mapping is one of the tasks you'll really enjoy doing with a tablet more than any other device.

Contributing to OpenStreetMap part 1: Why I decided to get involved

Written by Paul Kocialkowski - 24 november 2012 - no comments

I have been contributing to OpenStreetMap since years now, and only rarely wrote about it, while there is actually a lot to say about the whole experience. I'll be presenting my feedback over the project in a series of articles, starting with this one.

So first thing's first: let's talk a bit about why I care about the OpenStreetMap project. You may have understood from this blog that I am a computer programmer involved in free software development. Though, the reasons behind my involvement in OSM aren't quite exactly the same as the ones that explain why I care about free software. While free software is mostly about giving back to the user control over their computing, OSM is related to data, not software.

Both software and data have legal owners, who can restrict the use that is made of them. In the case of software, that restriction can be made to a point where it becomes obvious that the user doesn't get enough rights to still control the computing they do with such software: we call that lacking freedom. That is why the free software movement was started years ago, coming with a solution in the form of legal licenses assuring the user basic freedom, denying unjust powers to the software copyright holder. That's the main reason why I believe free software matters.

Though, when it comes to data, the question doesn't remain quite the same. First, data released with a permissive license or with a strict license will look the very same, and the license can change without any change made to the data itself. This is not the case for software: a permissive license is pretty much useless if no source code is ever released: that means free software needs to be released with source code, while a music will sound just the same whether it's under a permissive license or not. Another point is that software can harm, data usually can't. Computers make it incredibly easy to spy on people, track them, read their online conversations, etc. That's why it is so obvious non-free software is bad: with such issues at stake, you'd better be in control of your computing. Data is instead pretty much harmless. So it seems clear to me that what is at stake for software makes the need of free software very obvious while for data, the issues aren't as serious and the experience you get from the data will remain the same.

Well, strictly the same isn't quite true. There must be something more that comes with content under a permissive license. Of course, that's the ability to edit, remix, reuse and share the content. Now I think it's all about a personal consideration: whether you think it is ok to forbid the user from doing these things. I personally believe that such rights should be guaranteed and the fact that guaranteeing them would perhaps harm sales rate isn't a good enough justification to refuse them, compared to the benefits of sharing culture among people. And yes, we can find other ways to let the authors of the content live of what they're doing, it just needs to be fair enough between the authors and the public. So this is why I believe data, content should be licensed under permissive licenses. I won't get too much into details there, about under what conditions exactly I find the bargain fair, but it's worth writing about. Also, note that even though I disapprove the licensing of content under restrictive licenses, I do not see any reason to refuse using it under the given terms since, as I wrote before, it seems to do no harm and basically, using it with the involved restrictions seems better than doing nothing. With these elements cleared up, we can get to why I decided to get involved in OpenStreetMap.

Maps are just another type of data, licensed under the same rules as any other content. As a matter of fact, all of the serious maps providers were licensing their maps under restrictive licenses, which I, just like the people behind OSM, disapprove. I could have just decided to pick one and use it anyway, but OpenStreetMap was there. As its name suggests, OpenStreetMap provides maps under a permissive license, that used to be the Creative Commons BY-SA license and recently changed to the Open Database License (ODbL). It's also doing more than just providing content: it is also a community effort, that lets everyone contribute to the map! At some point, I got a Neo Freerunner, with GPS capability, so I just told myself: hey, why not try and contribute to the effort, I have everything that is needed for that (which is basically only a GPS).