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 that. 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 out. 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 - 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 GNU/Linux. * 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 dependencies. 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 Android. - 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 drivers. * 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 worked. * 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 IRC. * 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. References: ----------- [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/ [10] https://gitlab.freedesktop.org/mesa/mesa/blob/83b64ffc2c6d86bc67ad6c5e05f887160a89852a/Android.mk#L92 [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 [14] https://libreplanet.org/wiki/Group:Hardware/FSDG_distributions_comparison [15] https://libreplanet.org/wiki/Group:Hardware/Freest/e-readers/Aura_H2O_Edition_2 [16] https://libreplanet.org/wiki/Group:Hardware/research/e-readers/Kobo/glo_HD [17] https://libreplanet.org/wiki/Group:Hardware [18] https://framagit.org/GNUtoo/coreboot-scripts [19] https://libreplanet.org/wiki/Group:Hardware/research/gpu/radeon [20] https://libreplanet.org/wiki/Group:Defective_by_Design/Day_Against_DRM_2019 [21] https://libreplanet.org/wiki/Group:Defective_by_Design/Day_Against_DRM_2019/Free_Culture_Educational_Books GNUtoo, dllud and GrimKriegor
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
