[Replicant] Report from XDC 2019

dllud 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
in Canada.

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[1].

The conference was of particular interest to the effort of providing
fast and reliable graphics acceleration on Replicant 9[3] 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[4]. Keeping an eye on that project may yield valuable
  patches and insights to be applied on drm-hwcomposer[5].

* DRM database - emersion, the main developer behind libliftoff, also
  handles a very useful database on the DRM hardware and drivers'
  capabilities[6]. The pixel format data[7] 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
    (like replicant-6.0).
  - 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[8] by Soong[9].
  - 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[10].
  - 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
  in GNU/Linux.
  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
  run Replicant.
  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[11]. 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[12] would
    boot on other computers than the Librem5[14].

* 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[15] 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
  in GNU/Linux.
  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
      as well.
    - 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[16].

* LibrePlanet wiki - Some discussions about the LibrePlanet wiki also
  took place as he's also involved in documenting hardware freedom in
  this wiki[17]. As a result of that more contributions were made in
  that wiki.

* Libreboot flashing without soldering - He also took the opportunity
  to validate his scripts[18] 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[19].

* 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[13]
  (like Parabola) in the future.

* There was also a protest and workshop against DRM[20]. 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[21], 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.

 [1] The link to the recording can be found on the event page[2].
     The video can probably be downloaded without running nonfree
     JavaScript with youtube-dl.
 [2] https://xdc2019.x.org/event/5/
 [3] https://redmine.replicant.us/projects/replicant/wiki/GraphicsReplicant9
 [4] https://github.com/emersion/libliftoff
 [5] https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
 [6] https://drmdb.emersion.fr
 [7] https://drmdb.emersion.fr/formats?plane=1
 [8] https://en.wikipedia.org/wiki/Ninja_(build_system)
 [9] https://android.googlesource.com/platform/build/soong/
[11] https://libreplanet.org/wiki/Group:Hardware/Components/SOCs
[12] PureOS is a GNU/Linux distribution approved by the FSF[13]
[13] https://www.gnu.org/distros/free-distros.html
[17] https://libreplanet.org/wiki/Group:Hardware
[18] https://framagit.org/GNUtoo/coreboot-scripts
[19] https://libreplanet.org/wiki/Group:Hardware/research/gpu/radeon

GNUtoo, dllud and GrimKriegor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20191029/cfed9a92/attachment.asc>

More information about the Replicant mailing list