Search Results: "Thadeu Lima de Souza Cascardo"

10 November 2017

It's been some time since I last wrote. Life and work have been busy. At
the same time, the world has been busy, and as I would love to write a
larger post, I will try to be short here. I would love to touch on the
Librem 5 and
postmarketOS. In fact, I had, in a podcast
in Portuguese, Papo Livre. Maybe, I'll touch
a little on the latter.
Some of the inspiration for this post include:

All of those led me to understand how software freedom is under attack,
in particular how copyleft in under attack. And, as I talked during
FISL, though many might say that "Open Source has won", end users
software freedom has not. Lots of companies have co-opted "free
software" but give no software freedom to their users. They seem friends
with free software, and they are. Because they want software to be free.
But freedom should not be a value for software itself, it needs to be a
value for people, not only companies or people who are labeled software
developers, but all people.
That's why I want to stop talking about free software, and talk more
about software freedom. Because I believe the latter is more clear about
what we are talking about. I don't mind that we use whatever label, as
long as we stablish its meaning during conversations, and set the tone
to distinguish them. The thing is: free software does not software
freedom make. Not by itself. As Bradley Kuhn puts it: it's not magic
pixie dust.
Those who have known me for years might remember me as a person who
studied free software licenses and how I valued copyleft, the GPL
specifically, and how I concerned myself with topics like license
compatibility and other licensing matters.
Others might remember me as a person who valued a lot about upstreaming
code. Not carrying changes to software openly developed that you had not
made an effort to put upstream.
I can't say I was wrong on both accounts. I still believe in those
things. I still believe in the importance of copyleft and the GPL. I
still value sharing your code in the commons by going upstream. But I
was certaily wrong in valuing them too much. Or not giving as much or
even more value to distribution efforts of getting software freedom to
the users.
And it took me a while in seeing how many people also saw the GPL as a
tool to get code upstream. You see that a lot in Linus' discourse about
the GPL. And that is on the minds of a lot of people, who I have seen
argue that copyleft is not necessary for companies to contribute code
back. But that's the problem. The point is not about getting code
upstream. But about assuring people have the freedom to run a modified
version of the software they received on their computers. It turns out
that many examples of companies who had contributed code upstream, have
not delivered that freedom to their end-users, who had received a
modified version of that same software, which is not free.
Bradley Kuhn also alerts us that many companies have been replacing
copyleft software with non-copyleft software. And I completely agree
with him that we should be writing more copyleft software that we hold
copyright for, so we can enforce it. But looking at what has been
happening recently in the Linux community about enforcement, even
thought I still believe in enforcement as an strategy, I think we need
much more than that.
And one of those strategies is delivering more free software that users
may be able to install on their own computers. It's building those
replacements for software that people have been using for any reason. Be
it the OS they get when they buy a device, or the application they use
for communication. It's not like the community is not doing it, it's
just that we need to acknowledge that this is a necessary strategy to
guarantee software freedom. That distribution of software that users may
easily install on their computers is as much or even more valuable than
developing software closer to the hacker/developer community. That doing
downstream changes to free software in the effort of getting them to
users is worth it. That maintaining that software stable and secure for
users is a very important task.
I may be biased when talking about that, as I have been shifting from
doing upstream work to downstream work and both on the recent years. But
maybe that's what I needed to realize that upstreaming does not
necessarily guarantees that users will get software freedom.
I believe we need to talk more about that. I have seen many people dear
to me disregard that difference between the freedom of the user and the
freedom of software. There is much more to talk about that, go into
detail about some of those points, and I think we need to debate more. I
am subscribed to the
libreplanet-discuss mailing list.
Come join us in discussing about software freedom there, if you want to
comment on anything I brought up here.
As I promised I would, I would like to mention about postmarketOS, which
is an option users have now to get some software freedom on some mobile
devices. It's an effort I wanted to build myself, and I applaud the
community that has developed around it and has been moving forward so
quickly. And it's a good example of a balance between upstream and
dowstream code that gets to deliver a better level of software freedom
to users than the vendor ever would.
I wanted to write about much of the topics I brought up today, but
postponed that for some time. I was motivated by recent events in the
community, and I am really disappointed at some the free software
players and some of the events that happened in the last few years. That
got me into thinking in how we need to manifest ourselves about those
issues, so people know how we feel. So here it is: I am disappointed at
how the Linux Foundation handled the situation about Software Freedom
Conversancy taking a case against VMWare; I am disappointed about how
Software Freedom Law Center handled a trademark issue against the
Software Freedom Conservancy; and I really appreciate all the work the
Software Freedom Conservancy has been doing. I have supported them for
the last two years, and I urge you to
become a supporter too.

6 July 2017

I had been using my Samsung Galaxy S Relay 4G for almost three years
when I decided to get a new phone. I would use this new phone for daily
tasks and take the chance to get a new model for hacking in the future.
My apexqtmo would still be my companion and would now be more available
for real hacking.
And so it also happened that its power button got stuck. It was not the
first time, but now it would happen every so often, and would require me
to disassemble it. So I managed to remove the plastic button and leave
it with a hole so I could press the button with a screwdriver or a
paperclip. That was the excuse I needed to get it to running Debian
only.
Though it's now always plugged on my laptop, I got the chance to hack on
it on my scarce free time. As I managed to get a kernel I built myself
running on it, I started fixing things like enabling devtmpfs. I didn't
insist much on running systemd, though, and kept with System V. The Xorg
issues were either on the server or the client, depending on which
client I ran.
I decided to give a chance to running the Android userspace on a chroot,
but gave up after some work to get some firmware loaded.
I managed to get the ALSA controls right after saving them inside a
chroot on my CyanogenMod system. Then, restoring them on Debian allowed
to play songs. Unfortunately, it seems I broke the audio jack when
disassembling it. Otherwise, it would have been a great portable audio
player. I even wrote a small program that would allow me to control mpd
by swiping on the touchscreen.
Then, as Debian release approached, I decided to investigate the
framebuffer issue closely. I ended finding out that it was really a bug
in the driver, and after fixing it, the X server and client crashes were
gone. It was beautiful to get some desktop environment running with the
right colors, get a calculator started and really using the phone as a
mobile device.
There are two lessons or findings here for me. The first one is that the
current environments are really lacking. Even something like GPE can't
work. The buttons are tiny, scrollbars are still the only way for
scrolling, some of the time. No automatic virtual keyboards. So, there
needs to be some investing in the existing environments, and maybe even
the development of new environments for these kinds of devices. This was
something I expected somehow, but it's still disappointing to know that
we had so much of those developed in the past and now gone. I really
miss Maemo. Running something like Qtopia would mean grabing a very old
unmaintained software not available in Debian. There is still matchbox,
but it's as subpar as the others I tested.
The second lesson is that building a userspace to run on old kernels
will still hit the problem of broken drivers. In my particular case,
unless I wrote code for using Ion instead of the framebuffer, I would
have had that problem. Or it would require me to add code to
xorg-xserver that is not appropriate. Or fix the kernel drivers of
available kernel sourcecodes. But this does not scale much more than
doing the right thing and adding upstream support for these devices.
So, I decided it was time I started working on upstream support for my
device. I have it in progress and may send some upstream patches soon. I
have USB and MMC/SDcard working fine. DRM is still a challenge, but
thanks to Rob Clark, it's something I expect to get working soon, and
after that, I would certainly celebrate. Maybe even consider starting
the work on other devices a little sooner.
Trying to review my post on GNU on
smartphones, here is where I would put some
of the status of my device and some extra notes.
On Halium
I am really glad people started this project. This was one of the things
I criticized: that though Ubuntu Phone and FirefoxOS built on Android
userspace, they were not easily portable to many devices out there.
But as I am looking for a more pure GNU experience, let's call it that,
Halium does not help much in that direction. But I'd like to see it
flourish and allow people to use more OSes on more devices.
Unfortunately, it suffers from similar problems as the strategy I was
trying to go with. If you have a device with a very old kernel, you
won't be able to run some of the latest userspace, even with Android
userspace help. So, lots of devices would be left unsupported, unless we
start working on some upstream support.
On RYF Hardware
My device is one of the worst out there. It's a modem that has a
peripherical CPU. Much has already been said about Qualcomm chips being
some of the least freedom-friendly. Ironically, it's some with the best
upstream support, as far as I found out while doing this upstreaming
work. Guess we'll have to wait for opencores, openrisc and risc-v to
catch up here.
Diversity
Though I have been experimenting with Debian, the upstream work would
sure benefit lots of other OSes out there, mainly GNU+Linux based ones,
but also other non-GNU Linux based ones. Not so much for other kernels.
On other options
After the demise of Ubuntu Phone, I am glad to see
UBports catching up. I hope the project is
sustainable and produce more releases for more devices.
Rooting
This needs documentation. Most of the procedures rely on booting a
recovery system, which means we are already past the root requirement.
We simply boot our own system, then. However, for some debugging
strategies, getting root on the OEM system is useful. So, try to get
root on your system, but beware of malware out there.
Booting
Most of these devices will have their bootloaders in there. They may be
unlocked, allowing unsigned kernels to be booted. Replacing these
bootloaders is still going to be a challenge for another future phase.
Though adding a second bootloader there, one that is freedom respecting,
and that allows more control on that booting step to the user is
something possible once you have some good upstream support. One could
either use kexec for that, or try to use the same device tree for
U-Boot, and use the knowledge of the device drivers for Linux on writing
drivers for U-Boot, GRUB or Libreboot.
Installation
If you have root on your OEM system, this is something that could be
worked on. Otherwise, there is
magic-device-tool,
whose approach is one that could be used.
Kernels
While I am working on adding Linux upstream support for my device, it
would be wonderful to see more kernels supporting those gadgets.
Hopefully, some of the device driver writing and reverse engineering
could help with that, though I am not too much optimistic. But there is
hope.
Basic kernel drivers
Adding the basic support, like USB and MMC, after clocks, gpios,
regulators and what not, is the first step to a long road. But it would
allow using the device as a board computer, under better control of the
user. Hopefully, lots of eletronic garbage out there would have some use
as control gadgets. Instead of buying a new board, just grab your old
phone and put it to some nice use.
Sensors, input devices, LEDs
There are usually easy too. Some sensors may depend on your modem or
some userspace code that is not that easily reverse engineered. But
others would just require some device tree work, or some small input
driver.
Graphics
Here, things may get complicated. Even basic video output is something I
have some trouble with. Thanks to some other people's work, I have hope
at least for my device. And using the vendor's linux source code, some
framebuffer should be possible, even some DRM driver. But OpenGL or
other 3D acceleration support requires much more work than that, and, at
this moment, it's not something I am counting on. I am thankful for the
work lots of people have been doing on this area, nonetheless.
Wireless
Be it Wifi or Bluetooth, things get ugly here. The vendor driver might
be available. Rewriting it would take a long time. Even then, it would
most likely require some non-free firmware loading. Using USB OTG here
might be an option.
Modem/GSM
The work of the Replicant folks on that is what gives me some hope that
it might be possible to get this working. Something I would leave to
after I have a good interface experience in my hands.
GPS
Problem is similar to the Modem/GSM one, as some code lives in
userspace, sometimes talking to the modem is a requirement to get GPS
access, etc.
Shells
This is where I would like to see new projects, even if they work on
current software to get them more friendly to these form factors. I
consider doing some work there, though that's not really my area of
expertise.
Next steps
For me, my next steps are getting what I have working upstream, keep
working on DRM support, packaging GPE, then experimenting with some
compositor code. In the middle of that, trying to get some other devices
started.
But documenting some of my work is something I realized I need to do
more often, and this post is some try on that.

I had been using my Samsung Galaxy S Relay 4G for almost three years
when I decided to get a new phone. I would use this new phone for daily
tasks and take the chance to get a new model for hacking in the future.
My apexqtmo would still be my companion and would now be more available
for real hacking.
And so it also happened that its power button got stuck. It was not the
first time, but now it would happen every so often, and would require me
to disassemble it. So I managed to remove the plastic button and leave
it with a hole so I could press the button with a screwdriver or a
paperclip. That was the excuse I needed to get it to running Debian
only.
Though it's now always plugged on my laptop, I got the chance to hack on
it on my scarce free time. As I managed to get a kernel I built myself
running on it, I started fixing things like enabling devtmpfs. I didn't
insist much on running systemd, though, and kept with System V. The Xorg
issues were either on the server or the client, depending on which
client I ran.
I decided to give a chance to running the Android userspace on a chroot,
but gave up after some work to get some firmware loaded.
I managed to get the ALSA controls right after saving them inside a
chroot on my CyanogenMod system. Then, restoring them on Debian allowed
to play songs. Unfortunately, it seems I broke the audio jack when
disassembling it. Otherwise, it would have been a great portable audio
player. I even wrote a small program that would allow me to control mpd
by swiping on the touchscreen.
Then, as Debian release approached, I decided to investigate the
framebuffer issue closely. I ended finding out that it was really a bug
in the driver, and after fixing it, the X server and client crashes were
gone. It was beautiful to get some desktop environment running with the
right colors, get a calculator started and really using the phone as a
mobile device.
There are two lessons or findings here for me. The first one is that the
current environments are really lacking. Even something like GPE can't
work. The buttons are tiny, scrollbars are still the only way for
scrolling, some of the time. No automatic virtual keyboards. So, there
needs to be some investing in the existing environments, and maybe even
the development of new environments for these kinds of devices. This was
something I expected somehow, but it's still disappointing to know that
we had so much of those developed in the past and now gone. I really
miss Maemo. Running something like Qtopia would mean grabing a very old
unmaintained software not available in Debian. There is still matchbox,
but it's as subpar as the others I tested.
The second lesson is that building a userspace to run on old kernels
will still hit the problem of broken drivers. In my particular case,
unless I wrote code for using Ion instead of the framebuffer, I would
have had that problem. Or it would require me to add code to
xorg-xserver that is not appropriate. Or fix the kernel drivers of
available kernel sourcecodes. But this does not scale much more than
doing the right thing and adding upstream support for these devices.
So, I decided it was time I started working on upstream support for my
device. I have it in progress and may send some upstream patches soon. I
have USB and MMC/SDcard working fine. DRM is still a challenge, but
thanks to Rob Clark, it's something I expect to get working soon, and
after that, I would certainly celebrate. Maybe even consider starting
the work on other devices a little sooner.
Trying to review my post on GNU on
smartphones, here is where I would put some
of the status of my device and some extra notes.
On Halium
I am really glad people started this project. This was one of the things
I criticized: that though Ubuntu Phone and FirefoxOS built on Android
userspace, they were not easily portable to many devices out there.
But as I am looking for a more pure GNU experience, let's call it that,
Halium does not help much in that direction. But I'd like to see it
flourish and allow people to use more OSes on more devices.
Unfortunately, it suffers from similar problems as the strategy I was
trying to go with. If you have a device with a very old kernel, you
won't be able to run some of the latest userspace, even with Android
userspace help. So, lots of devices would be left unsupported, unless we
start working on some upstream support.
On RYF Hardware
My device is one of the worst out there. It's a modem that has a
peripherical CPU. Much has already been said about Qualcomm chips being
some of the least freedom-friendly. Ironically, it's some with the best
upstream support, as far as I found out while doing this upstreaming
work. Guess we'll have to wait for opencores, openrisc and risc-v to
catch up here.
Diversity
Though I have been experimenting with Debian, the upstream work would
sure benefit lots of other OSes out there, mainly GNU+Linux based ones,
but also other non-GNU Linux based ones. Not so much for other kernels.
On other options
After the demise of Ubuntu Phone, I am glad to see
UBports catching up. I hope the project is
sustainable and produce more releases for more devices.
Rooting
This needs documentation. Most of the procedures rely on booting a
recovery system, which means we are already past the root requirement.
We simply boot our own system, then. However, for some debugging
strategies, getting root on the OEM system is useful. So, try to get
root on your system, but beware of malware out there.
Booting
Most of these devices will have their bootloaders in there. They may be
unlocked, allowing unsigned kernels to be booted. Replacing these
bootloaders is still going to be a challenge for another future phase.
Though adding a second bootloader there, one that is freedom respecting,
and that allows more control on that booting step to the user is
something possible once you have some good upstream support. One could
either use kexec for that, or try to use the same device tree for
U-Boot, and use the knowledge of the device drivers for Linux on writing
drivers for U-Boot, GRUB or Libreboot.
Installation
If you have root on your OEM system, this is something that could be
worked on. Otherwise, there is
magic-device-tool,
whose approach is one that could be used.
Kernels
While I am working on adding Linux upstream support for my device, it
would be wonderful to see more kernels supporting those gadgets.
Hopefully, some of the device driver writing and reverse engineering
could help with that, though I am not too much optimistic. But there is
hope.
Basic kernel drivers
Adding the basic support, like USB and MMC, after clocks, gpios,
regulators and what not, is the first step to a long road. But it would
allow using the device as a board computer, under better control of the
user. Hopefully, lots of eletronic garbage out there would have some use
as control gadgets. Instead of buying a new board, just grab your old
phone and put it to some nice use.
Sensors, input devices, LEDs
There are usually easy too. Some sensors may depend on your modem or
some userspace code that is not that easily reverse engineered. But
others would just require some device tree work, or some small input
driver.
Graphics
Here, things may get complicated. Even basic video output is something I
have some trouble with. Thanks to some other people's work, I have hope
at least for my device. And using the vendor's linux source code, some
framebuffer should be possible, even some DRM driver. But OpenGL or
other 3D acceleration support requires much more work than that, and, at
this moment, it's not something I am counting on. I am thankful for the
work lots of people have been doing on this area, nonetheless.
Wireless
Be it Wifi or Bluetooth, things get ugly here. The vendor driver might
be available. Rewriting it would take a long time. Even then, it would
most likely require some non-free firmware loading. Using USB OTG here
might be an option.
Modem/GSM
The work of the Replicant folks on that is what gives me some hope that
it might be possible to get this working. Something I would leave to
after I have a good interface experience in my hands.
GPS
Problem is similar to the Modem/GSM one, as some code lives in
userspace, sometimes talking to the modem is a requirement to get GPS
access, etc.
Shells
This is where I would like to see new projects, even if they work on
current software to get them more friendly to these form factors. I
consider doing some work there, though that's not really my area of
expertise.
Next steps
For me, my next steps are getting what I have working upstream, keep
working on DRM support, packaging GPE, then experimenting with some
compositor code. In the middle of that, trying to get some other devices
started.
But documenting some of my work is something I realized I need to do
more often, and this post is some try on that.

1 September 2016

Some time ago, I built a static program that I wanted to run on an
Android tablet. What was my surprise when I saw a message saying
"FATAL: kernel too old".
After some investigation, it turns out that GNU libc may assume some
Linux features are present during build time. This means that given a
minimum Linux version, that built libc might only work on that version
or newer.
Since 2014, GNU libc itself requires 2.6.32 as the minimum. Previously,
it was 2.6.16, changed in 2012.
Debian, as of 2015, builds it with a required minimum Linux version of
3.2.
To give an idea about the history of these kernel releases, we have:

So, at least for GNU libc upstream, it would appear that not many
devices would stop being supported, though the situation would not be as
good for binary versions of Debian. However, I have a small list of
devices that might show otherwise.

Nokia N900 shipped with Linux 2.6.28.

Android emulator, a platform called Goldfish, uses Linux 2.6.29.

The Wii port most widely tested is based on Linux 2.6.32.

Many Android devices have been shipped with Linux 3.4, but I encountered
at least one using Linux 3.0.
So, even though many new devices ship with newer versions of Linux, it's
still possible to find some new and older devices using versions older
than 3.2, and even versions older than 2.6.32 may be found.
Another interesting note is that, without a few patches, it's not
possible to build Linux 2.6.32 with GCC 5 and newer. For that and many
other reasons, it's important that we update. For bug fixes, and so we
can make progress and use better software are some of the other reasons.
So, it's imperative that we have devices support upstream. Otherwise,
the task of doing updates with forward porting becomes daunting. And
that's the current state for many devices, which is why I have been
trying to use new software with older versions of Linux. But as time
passes, I realize how hard a task this is, as most new software these
days, even a building block like GNU libc, requires ever new versions of
Linux.
For now, most gadgets I have support Linux 3.4 or newer. But not long
ahead, that support will be dropped as well. And that means there will
be no more updates for those devices. It's a consequence of both
targeting time-to-market and programmed obsolescence as business
practices. Upstream support is no priority, and maintenance is only that
required until the next model is available on the stores.
This is one more reason why we need to have more operating systems
available for those devices. Systems that are designed to last more than
a couple of years. As I said, upstream support is imperative, but as a
step forward, I still believe we can provide the GNU experience to lots
of devices out there.

3 July 2016

On recent posts, I mentioned that I have a Chromebook, and that I would
like to run Debian on devices that ship with old Linux versions. The
Samsung ARM Chromebook is such a device, it has Linux 3.4, and that's
still what I am running on it most of the time.
After an upgrade of Debian, systemd stopped working, and it took me some
time before I could look into it. In order to boot, I had to temporarily
use System V init. The bug involves the use of new interfaces, bugs in
such interfaces, and how versioning would not be a solution to such
cases. Cases like this are not common, so it's no excuse to doing the
right thing when developing software, like considering portability, API
and ABI maintenance and not bundle. But they expose some of the
challenges when trying to support different OSes on top of old versions
of Linux, or maybe even new versions.
The new version of systemd included in Debian Jessie uses a feature of
Linux of checking the mount ID of a file by inspecting the mnt_id line
in the fdinfo files. fdinfo files are not that new, they have been
present since 2007, Linux 2.6.22. The mnt_id line, however, is from
Linux 3.15, from 2014. So, a fairly new feature. But systemd falls back
to other methods if the feature is not present.
However, during the last few weeks of development of Linux 3.4, a bug
was introduced to fdinfo handling, which will cause its access to fail
in a way that will cause systemd to halt. It simply will refuse to mount
the most basic filesystems and not proceed. The bug was fixed not much
longer than two weeks after that, but that window of time was enough to
have it on a shipped product, one that was not using systemd, let alone
one that required a feature not yet present on Linux.
But now I wanted to run this new systemd on this old Linux version.
Being too early in the boot process, systemd even ignored some of the
debug options and I had to resort to other methods of debugging. As I am
running a kernel I built by myself, it wasn't hard for me to have a
fixed kernel up and running after I found out the problem.
Unfortunately, not everyone will be able to do it by themselves. And the
point of getting different OSes working on these many varied devices is
scaling. If every device needs to be tested, we lose this scalability.
The other problem I found was that this old Linux version didn't load
firmware files by itself, and requested help from userspace, which used
to be the job of udev. Well, udev now does not support loading firmware,
and the kernel must do it by itself. I managed to backport that feature
too. But now, it sounds like I should get upstream support for this
device.
Unfortunately, this means not working on the scalability problem, but
going back to get upstream support for a lot of devices out there, which
is very hard to scale without the necessary people to do the work. I am
certainly going to do that, because it's the right thing to do. But not
as many people will benefit from that.
But I think it has been interesting to look into the possible problems
we might find when trying to make Debian and other OSes working on old
Linux versions. I know even older Debian versions won't boot fine on
Linux 2.6.32, one of the LTS versions of Linux. I have one other device
which runs on it, and I am also working on getting better upstream
support for it. Let's see if I can get some news on that soon.

14 May 2016

Three years ago, I wanted to get a new laptop. I wanted something that
could run free software, preferably without blobs, with some good amount
of RAM, good battery and very light, something I could carry along with
a work laptop. And I didn't want to spend too much. I don't want to make
this too long, so in the end, I asked in the store anything that didn't
come with Windows installed, and before I was dragged into the Macbook
section, I shouted "and no Apple!". That's how I got into the Chromebook
section with two options before me.
There was the Chromebook Pixel, too expensive for me, and the Samsung
Chromebook, using ARM. Getting a laptop with an ARM processor was
interesting for me, because I like playing with different stuff. I
looked up if it would be possible to run something other than ChromeOS
on it, got the sense that is, it would, and make a call. It does not
have too much RAM, but it was cheap. I got an external HD to compensate
for the lack of storage (only 16GB eMMC), and that was it.
Wifi does require non-free firmware to be loaded, but booting was a nice
surprise. It is not perfect, but I will see if I can get to that another
day.
I managed to get Fedora installed, downloading chunks of an image that I
could write into the storage. After a while, I backed up home, and
installed Debian using debootstrap.
Recently, after an upgrade from wheezy to jessie, things stopped
working. systemd would not mount the most basic partitions and would
simply stop very early in the boot process. That's a story on my backlog
as well, that I plan to tell soon, since I believe this connects with
supporting Debian on mobile devices.
After fixing some things, I decided to try libinput instead of synaptics
for the Trackpad. The Chromebook uses a Cypress APA Trackpad. The driver
was upstreamed in Linux 3.9. The Chrome OS ships with Linux 3.4, but had
the driver in its branch.
After changing to libinput, I realized clicking did not work. Neither
did tapping. I moved back to synaptics, and was reminded things didn't
work too well with that either. I always had to enable tapping.
I have some experience with input devices. I wrote drivers, small
applications reacting to some events, and some uinput userspace drivers
as well. I like playing with that subsystem a lot. But I don't have too
much experience with multitouch and libinput is kind of new for me too.
I got my hands on the code and found out there is libinput-debug-events.
It will show you how libinput translates evdev events. I clicked on the
Trackpad and got nothing but some pointer movements. I tried evtest and
there were some multitouch events I didn't understand too well, but it
looked like there were important events there that I thought libinput
should have recognized.
I tried reading some of libinput code, but didn't get too far before I
tried something else. But then, I had to let this exercise for another
day. Today, I decided to do it again. Now, with some fresh eyes, I
looked at the driver code. It showed support for left, right and middle
buttons. But maybe my device doesn't support it, because I don't
remember seeing it on evtest when clicking the Trackpad. I also
understood better the other multitouch events, they were just saying how
many fingers there were and what was the position of which one of them.
In the case of a single finger, you still get an identifier. For better
understanding of all this, reading Documentation/input/event-codes.txt
and Documentation/input/multi-touch-protocol.txt is recommended.
So, in trying to answer if libinput needs to handle my devices events
properly, or handle my device specially, or if the driver requires
changes, or what else I can do to have a better experience with this
Trackpad, things were tending to the driver and device. Then, after
running evtest, I noticed a BTN_LEFT event. OK, so the device and driver
support it, what is libinput doing with that? Running evtest and
libinput-debug-events at the same time, I found out the problem.
libinput was handling BTN_LEFT correctly, but the driver was not
reporting it all the time.
By going through the driver, it looks like this is either a firmware or
a hardware problem. When you get the click response, sound and
everything, the drivers will not always report it. It could be pressure,
eletrical contact, I can't tell for sure. But the driver does not check
for anything but what the firmware has reported, so it's not the driver.
A very interesting I found out is that you can read and write the
firmware. I dumped it to a file, but still could not analyze what it is.
There are some commands to put the driver into some bootloader state, so
maybe it's possible to play with the firmware without bricking the
device, though I am not sure yet. Even then, the problem might not be
fixable by just changing the firmware.
So, I left with the possibility of using tapping, which was not working
with libinput. Grepping at the code, I found out by libinput
documentation that tapping needs to be enabled. The libinput xorg driver
supports that. Just set the Tapping option to true and that's it.
So, now I am a happy libinput user, with some of the same issues I had
before with synaptics, but something you get used to. And I have a new
firmware in front of me that maybe we could tackle by some reverse
engineering.

11 January 2016

Some time ago, I wrote how to get GNU on a
smartphone. This is going to be a long discussion
on why and how we should work on more operating systems for more
devices.
On Android
So, why should we bother if we already have Android, some might ask? If
it's just because of some binary blobs, one could just use Replicant,
right?
Well, one of the problems is that Android development is done in hiding,
and pushed downstream when a new version is launched. There is no
community behind that anyone can join. Replicant ends up either
following it or staying behind. It could do a fork and have its own
innovations. And I am all for it. But the lack of manpower for
supporting devices and keeping up with the latest versions and security
fixes already takes most of the time for the one or two developers
involved.
Also, Android has a huge modularity problem, that I will discuss
further below. But it's hard to replace many components in the system,
unless you replace them all. And that also causes the problem that
applications can hardly share extra components.
I would rather see Debian running on my devices
and supporting good environments and frameworks for all kinds of
devices, like phones, tablets, TVs, cars, etc. It's developed by a
community I can join, it allows a diverse set of frameworks and
environments, and it's much easier to replace single components on such
a system.
On Copyleft Hardware
I get it. Hardware is not free or libre. Its design is. I love the
concept of copyleft hardware, where one applies the copyleft principles
to a hardware design. Also, there is the concept of Hardware that
Respects Your Freedom, that is, one that allows you to use it with only
free software.
Note that RYF hardware is not necessarily copyleft hardware. In fact,
most of the time, the original vendor has not helped at all, and it
required reverse engineering efforts by other people to be able to run
free software on those systems.
My point here is that we should not prevent people from running free
software on hardware that does not RYF or that is not copyleft. We
should continue the efforts of reverse engineering and of pushing
hardware vendors to not only ship free software for their hardware, but
also release their design under free licenses. But in the meantime, we
need to make free software flourish in the plethora of devices on the
hands of so many people around the world.
On Diversity
I won't go into details on this post about two things. One topic I love
is retrocomputing and how Linux supported so many devices, and how many
free or quasi-free operating systems ran on so many of them in the past.
I could mention ucLinux, Familiar, PDAs, Palmtops, Motorolas, etc. But I
will leave it to another time and go from Openmoko and Maemo forward.
The other topic is application scalability. Even Debian with so many
software available does not ship all free software there is available.
And it doesn't support all third-party services out there. How can we
solve that? It has to do with platforms, protocols, open protocols, etc.
I will not go into that today.
Because I believe that either way, it's healthy for our society to have
diversity. I believe we should have other operating systems available
for our devices. Even if application developers will not develop for all
of them. That is already the case today. There are other ways to fix
that, when that needs fixing. Sometimes, it's sufficient that you can
have your own operating system on your device, that you can customize
it, enhance it and share it with friends.
And also, that would allow for innovation. It would make possible that
some other operating system would have enough market share on some other
niche. Other than Android and iOS, for example. But that requires that
we can support that operating system on different devices.
And that is the scalability that I want to talk about. How to support
more devices with less effort.
Options
But before I go into that, let me write more about the alternatives we
have out there. And some of the history around it.
Openmoko
Openmoko developed a set of devices that had some free design. And it
has some free operating systems running on top. The community developed
a lot of their own as well. Debian could (still can) run on it. There
is SHR, which uses
FSO, a mobile middleware based on D-Bus.
It even spawned other devices to be developed, like GTA04, a
successor board, that can be shipped inside a Neo Freerunner
case.
Maemo, Moblin, Meego and Tizen
I remember the announcement of Nokia N770. During
FISL in 2005, I even criticized a lot, because it
shipped with proprietary drivers. And applications. But it was the first
time we heard of Maemo. It was based on Debian and
GNOME. The GNOME Mobile initiative was born from
that, I believe, but died later on.
But with the launch of N900, and later events, like the merge of
Moblin with Maemo, to create Meego, we all had an
operating system that was based on community developed components, that
had some community participation, and was much more like the systems we
were used to. You could run gcc on N900. You
could install Das U-Boot and have
other operating systems running there.
But Nokia has gone a different path. Intel has started
Tizen with Samsung. There is so much legacy there,
that could still be developed upon. I am just sad that Jolla decided to
put proprietary layers on top of that, to create
SailfishOS.
But we still have Mer,
Nemo. But it looks like
Cordia is gone. At least,
(http://cordiahd.org) seems to have been registered by a domain seller.
Not to forget, Neo900, a project to upgrade the
board, in the same vein as GTA04.
FirefoxOS and Ubuntu
What can I say about FirefoxOS and
Ubuntu Phone? In summary, I think we need
more than Web, and Canonical has a history of not being too community
oriented as we'd like.
I won't go too much here in what I think about the Web as a platform.
But I think we need a system that has more options for platforms. I
haven't participated in projects directed by Mozilla either, so I can't
say much about that.
Ubuntu Phone should be a system more like what we are used to. But
Canonical is going to set the directions to the project, it's not a
community project.
Nonetheless, I think they add to the diversity, and users should be able
to try them, or their free parts or versions. But there are challenges
there, that I think need to be discussed.
So, both of these systems are based on Android. They don't use Dalvik or
the application framework. But they use what is below that, which means
device drivers in userspaces, like RIL, for the modem drivers, and EGL,
for graphics drivers. The reason they do that is to build on top of all
the existing vendor support for Android. If a SOC and phone vendor
already supports Android, there should be not much needed to do to
support FirefoxOS or Ubuntu Phone.
In practice, this has not benefited the users or the projects. Porting
should be as simple as getting a generic FirefoxOS or Ubuntu Phone image
and run it on top of your Android or CyanogenMod port.
Porting usually requires doing all the same work as porting Android.
Even though one should be able to take advantage of existing ports, it
still requires doing a lot of integration work and building an entire
image, most of the time, including the upper layers, that should be
equal in all devices. This process should require at most creating a new
image based on other images and loading it on the device. I will discuss
more about this below.
I can't forget to mention the Matchstick TV
project. It is based on FirefoxOS. I think it would have much more
changes to succeed if it was easier for testers to have images available
for all of their gadgets capable of running some form of Android.
Replicant
And then we have Replicant. It has a lot of the problems Android has.
Even so, it's a tremendously important project. First, it offers a free
version of Android, removing all proprietary pieces. This is very good
for the community. But more than that, it tries to free the devices
beyond that.
What the project has been done is reverse engineer some of the pieces,
mostly the modem drivers. That allows other projects to build upon that
work, and support those modems. Without that, there is no telephony or
celullar data available on any of these devices. Not without proprietary
software, that is.
They also have been working on free bootloaders, which is another
important step for a completely free system.
Next steps
There are many challenges here, but I believe we should work on a set of
steps that make it more palatable and produce intermediary results that
can be used by users and other projects.
One of the goals should be good modularity. The ability to replace some
pieces with the least trouble necessary. The update of a single
framework library should be just a package install, instead of building
the entire framework again. If there is ABI breakage, users should still
be able to have access to binaries (and accompanying source code) and
only need to update the library and its reverse dependencies. If one
layer does not have these properties, at least it should be possible to
update this big chunk without interfering with the other layers.
One example is FirefoxOS and Ubuntu Phone. Even if there is a big image
with all system userspace and middleware, the porting, install and
upgrade process should allow the user to keep the applications and to
leverage porting already done by similar projects. Heck, these two
projects should be able to share porting efforts without any trouble.
So what follows is a quick discussion on Android builds, then
suggestions on how to approach some of the challenges.
On Android build
The big problem with Android build is its non-modularity. You need to
build the world and more to get a single image in the end. Instead of
packages that could be built independently, that generated modular
package images, that could be bundled in a single system image. Better
yet would be the ability to pick only those components that matter.
Certainly, portability would be just as interesting, being able to build
certain components on top a GNU system with GNU libc.
At times, it seems like this is done by design, to make it difficult for
"fragmentation" and competition. Basically, making it difficult to
exercise the freedom to modify the software and share your modifications
with others.
Imagine the possibilities of being able to:

Build Dalvik and the framework on a GNU system in order to run
Android programs on GNU systems.

Or build a single framework library that would be useful for your Java
project.

There are some dangers in promoting the use of Android like this. Since
it promotes proprietary drivers, relying on such layers instead of
better community oriented layers means giving an advantage to the first.
So, the best plan would be to replace those layers, when they are used,
for things like ofono and Wayland,
for example.
But, in the meantime, making it easier for users to experiment with
FirefoxOS, Ubuntu Phone, Matchstick TV, Replicant on other devices,
without resorting to building the entire Android system, would be a very
nice thing.
It is possible that there are some challenges with respect to API and
ABI. That these layers are too intermingled that some changes present in
one port would prevent FirefoxOS to run on top of it without changes in
either of the layers. I can't confirm that is the case, but can't deny
the possibility.
Rooting
One of the challenges we have that may have trouble in scaling is
rooting devices.
Unfortunately, most of the devices are owned by the vendor or carrier,
not the user. The user is prevented from replacing software components
in the system, by removing its permissions from replacing most of the
files in the filesystem, or writing to block devices, or change boot
parameters or write to the storage devices.
Fortunately, there are many documents, guides, howtos, and whatnots out
there instructing on how to root a lot of devices. In some cases, it
depends on software bugs that can be patched by the users as instructed
by vendors.
Certainly, favoring devices that are built to allow rooting, hacking,
etc, is a good thing. But we should still help those users out there who
do not have such devices, and allow them to run free software on them.
Booting
Then, comes booting, which is a large discussion on its own, and also
related to rooting, or how to allow users to replace their software.
First, we have the topic of bootloaders, which are usually not free, and
embedded in the chip, not on external storage. So, there are those
pieces of the bootloader which we can replace more easily and those that
we are not, because they would require changing a piece of ROM, for
example.
Das U-Boot would be one of the preferred options for a system. It
supports a lot of hardware platforms out there, a lot of storage devices
and filesystems, network booting, USB and serial booting, and a lot of
other things. Porting is not an easy task, but it is possible.
Meanwhile, using the bootloaders that ship with the system, when
possible, would allow a path where other pieces of the system would be
free.
One of the challenges here is building single images that could boot
everywhere. The lack of a single ARM boot environment is a curse and a
blessing. It makes it hard to have this single boot image, but, on the
other hand, it has allowed so much of the information for such systems
to be free, to be embedded in copyleft software, instead of having blobs
executed by our free systems, like ACPI encourages.
Device trees have pushed this portability issue from the kernel to the
bootloaders. Possibily encouraging vendors to now hide and copyright
this information in the form of proprietary device trees. But it has
made it easier for single images.
In practice, we still need to see a lot of devices out there supporting
this single kernel scenario. And this mechanism only brings us the
possibility of a single kernel. We still need to ship bootable images
that have pieces of bootloaders that are not as portable.
This has caused lots of operating systems out there to be built for a
single board. Or to support just a small set of boards. I struggle with
the concept. Why are we not able to mix device-specific pieces with
generic pieces and get a resulting image that will boot on our choice of
board? Why does every project need to do all the porting work again,
repeating the efforts? Or have one entier ISO image for every supported
board? Check how Geexbox does it, for an example.
Fortunately, I see Debian going in a good direction.
Here,
one can see how it instructs the user to combine a system-dependent part
with a system-independent part.
Installation
Which brings us to the installation challenge. We should make this easy
and also customizable by the user. Every project might have its own
method, and that is part of the diversity that we should allow.
The great challenge here is handling rooting and booting for the user.
But it's also possible to leave that as separate efforts, as it would be
nice to have good installers as we have in the desktop and server
environments.
Linux
Linux is one of the most ported kernels out there. Of course, it would
be healthy to the diversity I propose that other kernels and systems out
there should work on those mobile devices. NetBSD,
for example, has a reputation of being very portable and ported to many
platforms. And GNU runs on many of them, either together with the
original systems, or as the main system on top of other kernels, as
proven by the Debian
GNU/kFreeBSD port, which
uses GNU libc.
But, though I would love to see
HURD running directly on those
devices, Linux and its derivatives are already running on them. Easier
to tackle is to get
Linux-libre
running on those systems.
But though this looks like one of the easier tasks at hand, it is not.
If you run a derivative version from Linux, provided by the vendor,
things should go smooth. But most of the time, the vendor does not
provide patches upstream, and leave their fork to rot, if you are lucky,
in the earlier 3.x series.
And some times, there is not even source code available. There are
vendors out there who do not respect the GPL and that is one of the
reasons why GPL enforcement is important. I take this opportunity to
call attention to the work of Software Freedom
Conservancy and its current efforts to
raise funds to continue their
work.
Running an existing binary version of Linux on your device with a free
userspace is part of the strategy of replacing pieces one at a time
while allowing for good diversity and reaching more users.
Drivers
Then we have the matter of drivers. And in this case, it's not only
Linux drivers, but drivers running in userspace. Though others exist,
there are two important and common cases, which are modem and graphics
drivers, both of which are usually provided by Android frameworks, and
that other systems try to leverage, instead of using alternatives that
are more community friendly.
In the case of modem drivers, Android uses its RIL. Besides not using a
Radio or Modem at all, there are two strategies for free versions. One
is using free versions of the drivers for RIL. That's what Replicant
does, because, well, it uses the other Android subsystems after all. The
other one is using a system that is developed by the community. ofono is
one that, even though it's an Intel iniative, looks more community
governed or open to community participation than any Android subsystem
ever was.
As for Graphics, Canonical even built its
Mir project with the goal of being able to
use Android GPU drivers. Luckily, there has been a lot of reverse
engineering efforts out there for a lot of those GPUs shipped with ARM
SoCs.
Then, we can use Mesa, Wayland and
X.org. Other option, until then, is just using a
framebuffer driver, possibly one that does not need any initialization,
depending on one done by the bootloader, for example.
Middleware and Shells
Plasma Active, that I just found out now is Plasma
Mobile, looks like a great system. Built by
folks behind KDE, we can expect great freedom to
come from it. Unfortunately, it suffers from what we have been
discussing here, which is lack of good device support, or shipping
images that run on top of single devices, without leveraging the porting
that has come before of other systems. Fortunately, that is just what I
want to accomplish with this effort.
FSO, that I mentioned before, is a good middleware, that we should try
to run on top of these devices. Running GNOME or Unity shell, and use
rpm or deb based systems, that's all part of the plan on diversity. You
could use systemd, or
System V init systems, whatever gives you the kicks.
It's not an easy task, since there are so many new things on these new
kinds of devices. Besides touch, there is telephony, which as I
mentioned, would be a good task for ofono. As for TV sets or dongles, I
would love to see OpenFlint, created by the
Matchstick TV guys, flourish out there and allow me to flint stuff from
my mobile phone running Debian into my TV dongle running Debian.
Project
So, is there a project out there you can start contributing to? Well, I
pointed out a lot of them. All of them make part of this plan.
Contributing to reverse engineering GPUs, or to Plasma Mobile, ofono,
GNOME, Linux-libre, bootloaders, Debian, and so many other projects.
My plans are to contribute in the scope of Debian and make sure it works
well on top of semi-liberated devices, and make sure there is a nice
user interface and good applications when using either GNOME or Plasma.
Integrating ofono is a good next step, but I am running ahead of myself.
Right now, I don't think there is need for an integrated effort. If you
think otherwise, please let me know. If you are doing something in this
direction, I would love to know.
Paul Wise reminded me to point out to the Debian
Mobile, where I will probably
contribute any documentation and other relevant results.
Thanks
There are some many people to thank, but I would like to remember Ian
Murdock, who created Debian, one of the projects who inspires me the
most. I think the best way to handle his passing is to celebrate what he
has helped create, and move forward, taking more free software to more
people in an easy and modular way.
I have been wanting to write something like this for a long time, so I
thank Chris Webber for inspiring me on
doing it.