[Replicant] Report from XDC 2019
dllud at riseup.net
Tue Oct 29 01:33:11 UTC 2019
On the beginning of October, thanks to the sponsorship of NLnet, 3
Replicant contributors (GNUtoo, dllud and GrimKriegor) attended the
X.Org Developer's Conference (XDC) 2019 that took place in Montreal
XDC is an event that gathers developers working on the major free-
software graphics projects, which power up the graphics stack for both
GNU/Linux and Android. Example projects are Linux DRM, Mesa, Wayland,
X11 and KDE.
Raw recordings of the event are already available online.
The conference was of particular interest to the effort of providing
fast and reliable graphics acceleration on Replicant 9 but many
other relevant topics were also discussed. Here follows a summary of
the major discussions/insights we had at XDC and that we would like
to share with people interested in Replicant.
== Android related topics ==
* KMS planes and compositors - The display drivers available on most
System on a Chip (SoC) support hardware planes. Planes are the image
buffers that the compositor must arrange to produce the final buffer
for display. The existence of hardware planes allows the compositor
to externalize part of its work to the hardware, making it both
faster and less power hungry. While some system components already
take advantage of hardware planes, we can get even better
performance improvements if the applications themselves decide to
choose a pixel format supported by the hardware planes. On Replicant
6, the biggest performance breakthroughs were achieved by using the
right pixel format.
While Android already supports the usage hardware planes, we
discovered that GNU/Linux applications could also use them thanks to
libliftoff. Keeping an eye on that project may yield valuable
patches and insights to be applied on drm-hwcomposer.
* DRM database - emersion, the main developer behind libliftoff, also
handles a very useful database on the DRM hardware and drivers'
capabilities. The pixel format data is very useful for
Replicant, as one of the issues we face on Replicant 9 deals with
Adding dumps to the database is very easy: you only need to run one
command (drm_info -j | curl -d @- https://drmdb.emersion.fr/submit).
GNUtoo packaged drm_info in Parabola and contributed dumps for
several GPUs and SoCs, including the Exynos 4412 on the Galaxy SIII,
while still at the conference. He also found some issues that were
fixed by the drm_info developer.
* Backlight - GNUtoo talked about the backlight API with a developer
who worked on that API. When working to upstream the Galaxy SIII
backlight support, Putti had questions about whether the display
should be powered off when the backlight is set to 0. According to
her research we should not power off the display if we can as there
is a different API for that. We can also contact her for help on
this topic if we want to.
* Lima - While Lima is yet to be fully ready, we learned from the
developers that they now handled most errors spotted by piglit and
have shifted their focus into to real applications.
This means that they are willing to help us out as soon as we spot
any real issue with Lima on the Exynos 4412 with Android. At least
one Lima developer has an Exynos Single Board Computer (SBC) at
hand, meaning that they may be able to reproduce any bugs we find
Unfortunately we also leaned from them that, in order to know how
compliant Lima's GLES implementation is, there is no other way but
testing it in real-world scenarios. This is because the status in
features.txt is automatically generated according to which functions
are present in the code. This doesn't necessarily reflect how well
each function is implemented: for instance a function could be
present but empty.
* Panfrost - Panfrost is already capable of running SuperTuxKart on
GNU/Linux. Besides Alyssa, it now has many other developers helping
out, mostly sponsored by Collabora (a company). It seems now safe to
assume that Panfrost will reach GLES 3.2 compatibility, while Vulkan
is also on their minds. Porting Replicant to devices with a GPU
supported by Panfrost would be a good idea as we might be able to
leverage hardware 3D acceleration when Panfrost gets support for
* Vulkan - Vulkan will be required for new devices shipping with
Android 10, unless the device has a low amount of memory. Given that
Lima will never support Vulkan (the hardware itself isn't capable)
and that Panfrost will still take a while to get there, making sure
that Replicant 9 would still be usable without 3D hardware, proved
to be a good strategical decision. While Mesa has no software-only
implementation of Vulkan, SwiftShader has one, and it also runs on
* SwiftShader - We learned from Nicolas Capens, the lead engineer on
SwiftShader, that devices lacking hardware division CPU instructions
haven't been supported for a long time. Since the CPU of the devices
currently supported by Replicant lack such instructions, we need to
fix SwiftShader. Hopefully, upstream will happily accept patches for
that. The Android emulator (cuttlefish) is also using SwiftShader,
and components of the upstream graphic stack, however unlike
Replicant, it has hardware 3D acceleration through VirGL.
* Mesa and Android build systems - We talked with Alistair Delva from
Google about the design of the Android build system. He is not part
of the Android build system team but he seemed to know a lot about
their concerns and design decisions.
For some background:
- Most GNU/Linux programs (like VLC) use one of many build systems
available (like make, Autotools, CMake, etc). Thanks to that, when
you compile a program you usually run some commands like
make && make install or ./configure && make && make install
instead of running GCC directly.
- Most GNU/Linux distributions use package managers, which can be
used by the distribution's build system too. Thanks to that, we
don't have to build every program by hand by running make && make
install or ./configure && make && make install. They also handle
For instance, in Parabola, for each package, you have one file
(named PKGBUILD) that has some information (license, package name,
etc) and shell commands to build the package. Once built, the
package can be reused as dependency for building other packages.
- In the Android build system there is no package manager. Each
software component used has to be in a git repository. That
repository is cloned somewhere inside the main build directory
- Android also expects every single software component to be
converted to the build system they use (which is Blueprint for
Android 9). While there is some compatibility with the older
Android build system which used Android.mk, it doesn't integrate
well with recent Blueprint.
- With Blueprint, a developer writes .bp files that are then
converted to ninja by Soong.
- For projects like Linux or the toolchain, Google simply builds
them separately and uses the resulting binary in the Android build
system. This works because they don't need to build them for
- External projects like Mesa, that are integrated in Android,
cannot be built separately as they need to be built for Android's
libc. In such case, Google expects people to create tools that
convert from the program build system (make, Autotools, CMake,
etc) to the one currently used by Android (Blueprint).
Supporting Blueprint would give us several advantages:
- Projects like Mesa maintain Android.mk files. Blueprint would
enable support for newer Android version without ugly if-causes.
- Blueprint would allow for faster build times and automatic
recompilation when the source-files change on disk, instead of
having to manually force clean and rebuild Mesa, which slows down
development a lot.
However, it would be way better if Android supported some form of
packages and if it was able to wrap other build systems like is done
Adding Blueprint support to all external software components would
be quite time consuming and might not be sustainable, as the Android
build system may change again in the future.
If we take this route, in Replicant we would need to have tools
to convert from at least:
- Meson: to build Mesa
- Autotools: to build GNU/Linux userspace tools like busybox or evtest
- Kconfig: to build Linux and bootloaders
While some GNU/Linux build systems like Yocto already support the
features required by Google (forcing build flags, reproducible builds,
high parallelism across many machines, etc), we felt, when talking
with Alistair Delva (who isn't part of build system team), that they
wouldn't want to switch to something like Yocto, even if all their
technical requirements are met. Despite trying, we didn't manage to
get a clear answer on why that would be the case.
* Companies and politics - We also assisted to a political discussion
about testing Android, and the Generic kernel image (GKI), that
happened between someone from Google and a hardware vendor.
That kernel image is used as part of the Android compliance test
suite. Vendors can use their own free software kernel modules and
userspace drivers in a separate partition, but not their own kernel
image during testing. Because of that, the build configuration used
by Google is important for hardware vendors. In that conversation a
hardware vendor was pushing Google to include support for specific
kernel configurations and SBCs in their test farm.
* Replicant phone offer - The person behind the Libre Computer company
mentioned to us that he would be willing to make a phone meant to
However given that we are currently busy with making a Replicant 6
release and porting Replicant to Android 9 we probably won't have
the time to look into it soon.
Once Replicant 9 is ready for the Galaxy SIII and Note II, we would
also need to look into the Librem5 and the PinePhone before that to
see if/how we could add support for them, and do it if we manage to
find the time.
== Workflow and project management ==
* GitLab - We learned the result of the migration of libinput to GitLab:
- It enabled to run some automatic tests in GitLab
- Nobody was reviewing patches anymore (0 reviews in total)
In Replicant we don't use GitLab anymore, and many of the patches
sent to the mailing list are reviewed.
* Generic code and testing - The code in the graphic stack was made more
generic. This required more testing on real hardware to spot issues.
In Replicant 9, we're trying to make the code more generic, so we'll
probably need to do more testing as well.
* Shipping test utilities - Shipping the test utilities in a separate
source repository creates issues as distributions tend to not package
it. Users then cannot easily use the utilities to help investigate
issues. It would be a good idea to ship test utilities in Replicant
images as well to help users diagnose (hardware and software) issues.
* Testing - Several talks gave us good insights on testing of workflows.
== Non-Android / Other topics ==
* Libre Computer - At the conferences, the attendees got a "Libre
Computer" AML-S805X-AC, along with some accessories required to do
development for it.
- The vendor contracted a company (probably Bay Libre) to add support
for it in upstream Linux and u-boot. However several nonfree
binaries are still needed to boot it. After the conference, GNUtoo
took the time to find more information about the nonfree bootloader
components. As the hardware support is in a upstream project
it's faster and easier to find such information.
- This SBC was used to test if the arm64 version of PureOS would
boot on other computers than the Librem5.
* GNUtoo also learned that some of the 8051 processors had no stack and
limited memory. This is relevant to Replicant, because the firmware
of several WiFi chips (Realtek 8188F and other) were released as
GPL but without the corresponding source code. Since the GPL
explicitly allows reverse engineering, decompilation, etc, and as the
firmware is small (~22k) it makes them easier to reverse engineer.
* GNUtoo also learned that there is now a database for mice's DPI, and
that it is easy to add support for custom resolutions through udev.
There is also a mouse firmware emulator called ratbagd.
* GNUtoo also got some pointers on where to find proof of the hardware
requirements that companies like Netflix were imposing on hardware
manufacturers. If we can find out and prove exactly which companies
are imposing signed bootloaders on smartphones, it would probably help
the FSF anti-DRM campaigns. Later we all learned that HDCP had to be
bypassed to test GPUs hardware (for hardware manufacturing) and
* GNUtoo also discussed with someone wanting to write a free software
emulator that focused on running programs from another architecture
Unlike QEMU that is meant to be generic, optimizations could be made
to run 10 or 15x faster than qemu-user as programs don't need a full
hardware emulation. When reading, it could be interesting to run free
software that has not been ported or compiled to another architecture.
== Notable talks ==
* On day 3 of XDC, Alyssa gave a peculiar talk on how to do reverse
engineering (RE). This talk used magic as a metaphor to explain RE.
As such, the ambiance was super fun, and made it more accessible to
beginners. It is available on the video of the third day from
2:38:15 to 3:04:15.
== FSF ==
After XDC, GNUtoo went to the FSF for a week. The first days he had
various issues with accommodation, which meant that most of the time
was spent looking for new accommodation in the area. After that he was
kindly hosted by someone working at the FSF. He could then resume work:
* Replicant Virtual Machines (VMs) - GNUtoo had previously been working
on making a Guix VM for Replicant but it still needs to be deployed
in the FSF infrastructure. That VM would enable anybody to easily
contribute to the Replicant infrastructure without requiring root
access. It would also allow the review of changes on the mailing list
and would enable changes to be tested locally. There were discussions
with the FSF sysadmins about the state of the Guix VM for Replicant:
- The FSF gave GNUtoo the script they use to create Trisquel VMs.
- We need to implement encryption for the Guix SD rootfs to be able
to deploy it at the FSF.
- We would be the first project to run Guix SD in their infrastructure.
- We would need either to give them an image or to modify the script
to allow for easy deployment.
- Backups may also need to be taken care of, but we might not need a
full VM backup with Guix if the configuration and the data are also
saved somewhere else.
* Discussions - A lot of discussions happened with various people at
the FSF on the following topics:
- DRMs and the relationship with the Management Engine and signed
bootloaders on Android smartphones and tablets.
- The Respect Your Freedom (RYF) certification:
- GNUtoo pointed to the FSF that the certification doesn't apply to
non commercial projects. They were interested in also enabling DIY
community projects to be certified as well. For instance,
instructions to do a Libreboot laptop yourself could be certified
- A lot of discussions on what hardware should and should not be
certified took place, along with explanations on how the hardware
* E-readers - As GNUtoo also worked to evaluate the freedom of the Kobo
Aura H2O Edition 2 e-reader for the FSF, he also made a demo of
Parabola on it, and had discussions on how to fund work to free its
WiFi firmware. He also reviewed a bit another e-reader.
* LibrePlanet wiki - Some discussions about the LibrePlanet wiki also
took place as he's also involved in documenting hardware freedom in
this wiki. As a result of that more contributions were made in
* Libreboot flashing without soldering - He also took the opportunity
to validate his scripts to flash Libreboot on a Thinkpad X200
Tablet without soldering and taught a sysadmin working at the FSF how
to do it. The hardware and software setup is probably not very
reliable but it worked fine. A better solution would be to design
hardware similar to what was used during the factory programming of
such laptops, as suggested by a Libreboot developer (swiftgeek) on
* Radeon GPUs - The FSF has given him a Lenovo G505s, with the
opportunity to ship it to people wanting to work on it to improve its
freedom. He tried to contact people on the Coreboot mailing list for
that. After the conference, and after installing Coreboot on it, he
worked to add support for its GPU in Linux-libre and started to
document Radeon GPU freedom status in the LibrePlanet wiki.
* POWER 9 - GNUtoo tried to install a Parabola chroot on a POWER 9
computer, to then work on booting Parabola on it but he didn't have
enough time to finish the bootstrap. The FSF will probably make that
computer accessible to developers of FSF approved distributions
(like Parabola) in the future.
* There was also a protest and workshop against DRM. We had fun
preparing the protest signs. At the protest we also learned from RMS
many tips to make it more efficient, like try to proactively give
flyers to people, or find ways to make people engage more with us.
In the workshop:
- Some people were contributing to online resources for teaching.
- Some people also started a list of existing books that could be used
for teaching, along with which curriculum they were made for.
Several countries have precise specifications for curriculum, and
because of that, the books often needs to be made specifically for
a given curriculum.
== Thanks ==
* We would like to thank Paul Kocialkowski, who attended XDC on behalf
of Bootlin, but was nonetheless a constant help on all topics related
to Replicant. Paul introduced us to many developers working on
projects that are relevant to Replicant and gave us much welcomed
help on some advanced graphics topics.
* We would also like to leave a special thanks to Régis, who in practice
was our host in Montreal. Despite being on a though work week, Régis
found the time to give us precious help navigating around the city.
* GNUtoo would also like to thanks Ian from the FSF for the hosting as
he would have been in deep trouble without it.
 The link to the recording can be found on the event page.
The video can probably be downloaded without running nonfree
 PureOS is a GNU/Linux distribution approved by the FSF
GNUtoo, dllud and GrimKriegor
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Replicant