{{>toc}} h1. Funding h2. Funding procedure h3. Background and rationale for funding work through the NLnet foundation The NLnet foundation managed to get some European Union grants to fund work on privacy and trust technologies. It's then up to individuals to apply to it, and to define tasks that can improve privacy and trust on the Internet, which then the NLnet foundation can choose to fund. This could for instance be used to fund the advancement of software (Tor, Replicant, etc) and hardware freedom (RISC-V, etc). The only requirement (beside improving privacy and trust) seem to be that the project needs to have an European Union component (like the people applying for the grant living in the European union, etc). They are then paid once tasks defined and/or the deliverables mentioned in the task have been completed. The NLnet foundation also have some resources to help pushing changes upstream and try to push the applicants into making their work as useful as possible by engaging with upstream communities. References: * "Fosdem Lightning talks on the topic":https://fosdem.org/2019/schedule/event/nextgen_internet/ h3. Tasks accepted for funding by the NLnet foundation * [[Tasks_funding#"Finish porting Replicant to a newer Android version" nlnet Grant application|Finish porting Replicant to a newer Android version]] * [[TasksFunding#Graphics-acceleration|Graphics acceleration]] The application criteria wrere handled by the NLnet foundation. h3. Discussions There is "a thread about funding on the mailing list":https://lists.osuosl.org/pipermail/replicant/2019-January/001774.html about that h3. Mistakes * When submitting a task to the NLnet Foundation make sure to select a call in "Please select a call", like "NGI Privacy & Trust Enhancing Technologies". I for instance forgot to select the right call. * The amount requested was too high as the grant is not taxed. The amount was changed after the submission and acceptation. h2. Port Replicant to a newer Android version h2. Documents MOU: * *Git*: https://git.replicant.us/contrib/GNUtoo/documents/tree/NLnet/porting_replicant_to_android9 * *Signed MOU from GNUtoo*: * *Signed MOU from both parties*: h3. Initial application (modified since) Replicant is currently based on LineageOS 13 which is based on Android 6.0. It is becoming very urgent to upgrade Replicant to a newer release of Android, as Android 6.0 is not supported anymore. It would probably also make it way easier to fix the following issues: * Replicant is currently lagging behind with security fixes * Replicant cannot be built from a GNU/Linux distribution that follows the Free Software Distribution Guidelines *Hardware requirements* : * A computer that is able to build Replicant. * A smartphone or tablet that can easily supported by the new version of Replicant and that meet Android 9 [[HardwareRequirements]]. *Expected outcomes*: * Remove all proprietary components of LineageOS and make sure that Replicant follows the "Free Software Distributions Guidelines (FSDG)":https://www.gnu.org/distros/" * Port all the changes needed to successfully boot without any proprietary software in Replicant * Make sure that most of the security issues are fixed, and lower the attack surface if possible. * Make sure that Replicant can be built on a GNU/Linux distribution that follows the "Free Software Distributions Guidelines (FSDG)":https://www.gnu.org/distros/ * Rebrand LineageOS as Replicant *Funding*: We applied to https://nlnet.nl/PET h3. NLnet foundation Grant application for "Finish porting Replicant to a newer Android version" h4. Contact information: |_. Your name | Denis Carikli | |_. Email address | [[PrivateContact#Email]] + our contact at the FSF | |_. Phone numbers | GNUtoo's phone number | |_. Organisation | Replicant and the FSF | |_. Country | France(Denis Carikli), USA (FSF) | h4. General project information |_. Project name | Finish porting Replicant to a newer Android version | |_. Website / wiki | https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9 | |_. Abstract: Can you explain the whole project and its expected outcome(s).in 1200 characters |
Replicant is a fully free software Android distribution which is approved by the FSF (http://gnu.org/distros). The combination of Android Open Source Project source code with the Linux source code provided by the device vendor is not sufficient to produce a fully free Android distribution that works: a lot of the code that makes critical hardware components work (the modem, graphics, audio, GPS, etc) is in userspace. Because of that, most device manufacturers don't release them as free software. To make such hardware work, the Replicant project manages to replace or avoid such nonfree software. Replicant is currently based on LineageOS 13.0 which in turn is based on Android 6.0.1 which are both not supported anymore. Replicant is based on LineageOS because it supports way more smartphones and tablets than the Android Open Source Project. The project consists in porting Replicant changes on top of the Android 9 release of the Android Open Source project, and when LineageOS 16 will be ready, to backport our changes on top of LineageOS 16.| |_. Have you been involved with projects or organizations relevant to this project before? And if so, can you tell us a bit about your contributions? | Yes: I've been involved in Replicant since the beginning both as a developer and for managing the project: As a developer: * I did most/all the initial system work and made it work for the the HTC Dream, and the Google Nexus One. * I also worked on porting the Goldelico GTA04, Galaxy nexus, Galaxy Tab 2 7.1 along with other Replicant developers and did various bug fixes and improvements. * I am also doing code reviews for patches. And as for managing the project I'm involved in: * public relations (blog posts, etc) * fund usage decisions * infrastructure (system administration with other developers, etc) * documentation * project direction and strategic decisions | h4. Requested support |_. Requested Amount (Between 5000 and 50000 Euros) | 50000 Euros | |_. Does the project have other funding sources, both past and present? | The Replicant project has about 200000 dollars at disposition: * The Replicant project has a donation page https://crm.fsf.org/civicrm/contribute/transact?reset=1&id=19. Part of the donations were used for buying devices and reimburse conference attendances. We have about 20000 dollars remaining from the donation. * The Replicant project recently received 200000 dollars from Handshake: https://www.fsf.org/news/free-software-foundation-receives-1-million-from-handshake As the FSF takes 10% that leaves us 180000 dollars | Explain what the requested budget will be used for?
The budget will only be used to fund this task through contract work. We think it will take something between 3 and 6 months of work for one full time developer. However it is always difficult to evaluate precisely the amount of time that this kind of project would take as sometimes it can be slowed down a lot due to bugs needing to be fixed. For instance, when adding support for the Nexus One to Replicant, a lot of time was spent dealing with display issues that didn't affect the upstream projects, because they relied on the GPU which required nonfree software to work. If we take the cost of a Freelance developer in the USA (75$ to 150$ per hour) as a basis, to enable people living in Europe and the USA to apply, we can fund a developer to work on it for a period that is mostly equivalent to something between 2 to 4 months full time. So far we have at least one person interested in working on it as a contractor (me), and one volunteer who wants to work on it at the same time, but who cannot do it full time. We will make sure that everybody has a chance to apply for doing contract work. If the work is not done when the 50000E run out, and if we cannot make sure that it will be completed by volunteers in a reasonable timeframe, the Replicant project will most probably use its existing funds to pay for contract work to make sure that this task is completed. The Replicant project will also take care of ensuring that the people that will work on this task have the necessary hardware to do it, for instance by shipping or reimbursing the purchase of a compatible smartphone with the Replicant project money. Once we have the Samsung Galaxy SIII fully working with Replicant 9, we will add support for most smartphones and tablets we currently support in Replicant, and add support for more recent smartphones (the most recent one we currently support has been released in 2013). We also have a very basic documentation on the Android 9 port here: https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9Compare your own project with existing or historical efforts.
Upgrading Replicant to a new Android version usually took about 2 or 3 months of full-time equivalent work for one person. Here, we already have a device (The Galaxy SIII 4G) booting under Android 9 master before the release, with a kernel that is closely based on upstream Linux, but a lot still needs to be done (modem, audio, sensors, etc) and validated. The Android architecture also changed a lot more between Android 6.0.1 and Android 9 than it did when we ported Replicant to newer Android versions.What are significant technical challenges you expect to solve during the project, if any?
We will also need to make sure that Replicant 9 can be built with a GNU/Linux distribution that is approved by the FSF. This could be challenging if they lack some of the packages required to build Android.Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?
This project will re-use code from several projects such as Android, drm-hwcomposer, Mesa and Lima driver. Whenever possible we will foster collaboration with these projects and submit our changes upstream. The Replicant project contributors and the FSF will supervise contractors to do the work. A blog post will announce that the Replicant project has got some funding for this specific task, and that it is looking for a contractor to work on it. This is to make sure that everyone has equal chances in the application process. Then the most suited contractor will be selected. Only contractors that already have worked on similar tasks as part of free and open source software projects will be chosen. This way we can look at their existing contributions and make sure that they are able to do the task before engaging with them. The Replicant project will also make sure that the contractor has or gets the hardware required to work on the task, before starting to work on it.|_. Attachments | None | h4. How may we handle your information |_. What should we do in the other case, e.g. when your project is not immediately selected? | I allow NLnet Foundation to keep the information I submit on record, should future funding opportunities arise | |_. Send me a copy of this application. | check-box checked | |_. PGP pubkey | None (if we use Replicant contact address, we can't encrypt to it) | h2. Graphics acceleration Currently, all supported devices on Replicant lack a free software driver for their GPU. This means that OpenGL ES (GLES) rendering must be done on the CPU (software rendering). The current approach to software rendering on Replicant 6 is based on "libAGL":https://android.googlesource.com/platform/frameworks/native/+/master/opengl, an optimized GLES 1.x implementation that uses "libpixelflinger":https://android.googlesource.com/platform/system/core/+log/master/libpixelflinger software renderer. Development on both these libraries ceased in 2013 and no work was done to support newer GLES versions. The major consequences of this are that: * Critical applications like web browsers crash due to lack of GLES 2.0 (#705). Replicant currently uses an out-dated browser that has many security flaws. * Replicant relies on patches to the Android framework to make things like the camera application work. * The rendering speed has degraded over the newer Android versions, like Android 6. Even applications that do not crash become difficult to use due to the huge rendering delays. This task aims to fix all these severe issues by putting together a new graphics stack for the Android 9 port. This new graphics stack must be compatible with Android 9 Hardware Abstraction Layers (HAL) and provide at least GLES 2.0 rendering. It should be flexible enough to do software rendering with "Mesa":https://www.mesa3d.org/intro.html or "SwiftShader":https://swiftshader.googlesource.com/SwiftShader (Google's current software renderer), and also GPU rendering on devices where a free GPU driver is available. "Joonas Kylmälä":https://redmine.replicant.us/users/8585 has done some introductory work on the Android 9 port for the i9305, and found a way to have it rendering to the screen. He put together a graphics stack composed of: gbm_gralloc ("Gralloc HAL":https://source.android.com/devices/graphics/implement#gralloc_hal) + drm_hwcomposer ("Hardware Composer HAL":https://source.android.com/devices/graphics/implement#hardware_composer_hal) + Mesa with kms_swrast driver with softpipe backend (CPU software renderer for GLES). This will be the starting point for this task. Joonas' prototype shows that Replicant can use "gbm_gralloc":https://osdn.net/projects/android-x86/scm/git/external-gbm_gralloc/summary, an existing graphics memory allocator (gralloc) HAL maintained(ish) by Android-x86, in conjunction with "drm-hwcomposer":https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer, a libre implementation of Android's Hardware Composer HAL based on Linux's DRM, to achieve software rendering with Mesa. This solution avoids the need to write a custom gralloc for Replicant, and takes advantage of the hardware acceleration for composition provided by drm-hwcomposer on devices with a free software DRM driver (e.g. exynos-based smartphones and tablets). Much more testing is needed to confirm that gbm_gralloc can be the definitive gralloc HAL on Replicant 9. It still wasn't tried with SwiftShader, or even Mesa's llvmpipe backend, which is a must since the softpipe backend is too slow to be usable. Joonas' tests showed that some other components will need our attention, mostly the drm/exynos driver. In order to make drm/exynos work with gbm_gralloc and drm-hwcomposer Joonas had to disable "DRM-Auth":https://en.wikipedia.org/wiki/Direct_Rendering_Manager#DRM-Master_and_DRM-Auth and hack some missing pixel formats into it by using the default pixel format for everything. Besides drm/exynos, we will also have to make the graphics stack work with the "virtual GEM (vGEM) driver":https://www.phoronix.com/scan.php?page=news_item&px=DRM-vGEM-Mesa-Software, in order to support devices that lack a real drm driver. The major and first goal of this task is thus to build upon Joonas's prototype and put together a stable and fully free graphics stack, compatible with GLES 2.0, that does software rendering through Mesa's llvmpipe with a decent performance. *Hardware requirements*: A computer that is able to build Replicant. A Samsung Galaxy S3 or S3 4G to run the [[Porting_Replicant_to_Android_9|current Replicant 9 port]]. *Difficulty*: Medium / Hard *Requirements/Prerequisites*: Knowledge of C++, kernel interfaces knowledge or the ability to learn them *Expected outcomes*: * Graphics stack with decent performance on software rendering * Working GLES 2.0 implementation * Fast enough graphics * F-Droid applications not crashing anymore because of GLES. *Time +estimation+*: |_. Step |_. man-hours | | Set up the development environment, including the current Replicant 9 port on the test device. |>. 24 | | Read AOSP documentation and understand all details of the graphics stack. |>. 16 | | Adapt the build files to use Mesa's llvmpipe backend instead of softpipe. Fix potential LLVM version incompatibilities between Mesa and Android. |>. 40 | | Properly implement the missing pixel formats in drm/exynos and try to have it merged into upstream. |>. 72 | | Find a proper way to use DRM-Master and DRM-Auth with gbm_gralloc and drm-hwcomposer. |>. 40 | | Create test scenarios and check if the graphics stack works as expected. Consider "alternative grallocs":https://redmine.replicant.us/projects/replicant/wiki/GraphicsResearch#Gralloc if necessary. |>. 40 | | Make the graphics stack work with vGEM driver besides drm/exynos. |>. 40 | | Document the design decisions. |>. 16 | |_. TOTAL |_>. 288 | h3. Subtasks The following sub-tasks could also be worked on after finishing writing the gralloc: * [[Tasks_funding#SwiftShader|SwiftShader]] * [[Tasks_funding#llvmpipe optimizations|llvmpipe optimizations]] * [[Tasks_funding#Lima driver|Lima driver]] h3. SwiftShader "SwiftShader":https://swiftshader.googlesource.com/SwiftShader is Google's current software renderer that is capable of GLES 2.0 and is now "under work to support Vulkan":https://swiftshader.googlesource.com/SwiftShader/+log/master. Mesa is the preferred renderer on Replicant for several reasons such as its support for both software and hardware (GPU) rendering, and its big community, with hundreds of active contributors. However, Mesa lacks a Vulkan software renderer. With Vulkan soon becoming a "requirement for new Android versions":https://android-developers.googleblog.com/2019/03/introducing-android-q-beta.html, we must make sure that Replicant's graphics stack can use SwiftShader in order to become futureproof. Furthermore, SwiftShader was built with performance in mind, specially for ARM CPUs, and may bring speed improvements on some devices. The goal of this sub-task is thus to create a compile-time or run-time option that allows using Replicant 9 with SwiftShader as it's software renderer instead of Mesa. *Hardware requirements*: A computer that is able to build Replicant. A smartphone or tablet that is supported by Replicant to be able to test the result. *Difficulty*: Medium *Requirements/Prerequisites*: Knowledge of C++, Makefiles and git. Android's graphics stack knowledge or the ability to learn them. *Expected outcomes*: * SwiftShader running on Replicant. * Working Vulkan implementation. *Time +estimation+*: 40 man-hours. h3. llvmpipe optimizations Mesa is a highly versatile library that can be extended with device drivers to allow it to be used in different environments ranging from software emulation to complete hardware acceleration. One such driver is the "Gallium llvmpipe driver":https://www.mesa3d.org/llvmpipe.html, which is a software rasterizer that uses LLVM to do runtime code generation. It only needs a CPU to run graphics computations and thus brings full GLES support to all Replicant devices. "llvmpipe has been integrated in Replicant 6":https://git.replicant.us/replicant/external_mesa3d/log/ but it's not activated by default yet as it is very slow. It is also not fully complete. To fix that, llvmpipe and/or the integration of it in Replicant should be optimized. We should first start by configuring llvmpipe and/or Mesa "to not implement very expensive OpenGL operations":https://www.mesa3d.org/perf.html. If that's not sufficient, or if that breaks application compatibility, various software or hardware features ("ARM NEON":https://www.arm.com/products/processors/technologies/neon.php, hardware 2D acceleration, etc) could be used to improve the speed. Considerable speed improvements may be achieved with a fine-tuned emulation for division instructions. The ARM cores on many Replicant devices do not have hardware "support for the SDIV/UDIV instructions":https://community.arm.com/processors/b/blog/posts/divide-and-conquer. We should profile some apps and check whether GLES functions requiring divisions are to blame for the poor performance. *Hardware requirements* : A computer that is able to build Replicant. A smartphone or tablet that is supported by Replicant to be able to test the result. *Difficulty*: Medium / Hard (depending on the amount of optimizations required) *Requirements/Prerequisites*: See with Mesa project *Expected outcomes*: faster llvmpipe on ARM devices, able to run apps such as Fennec F-Droid (Firefox). *Time +estimation+*: |_. Step |_. man-hours | | Setup a "testing and benchmarking environment":https://source.android.com/devices/graphics/testing |>. 40 | | Disable expensive OpenGL operations. Check speedup and stability. |>. 24 | | Recap matrix operations (Linear Algebra) and study ARM NEON. |>. 48 | | Do a profiling of several apps to find the most used GLES operations. |>. 32 | | Use "Ne10 library":https://github.com/projectNe10/Ne10 or "Neon Intrinsics":https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics for the most used GLES operations. |>. 80 | | Fix bugs, re-write the code where needed, get it stable. |>. 80 | |_. TOTAL |_>. 304 | h3. Lima driver "Lima":https://gitlab.freedesktop.org/lima is a free software Mesa driver for ARM Mali-4xx (Utgard) GPUs. These GPUs are present in several Replicant supported devices such as Galaxy S2, S3, S3 4G, Note and Note 2. Lima aims to full GLES support but it is still in development. However the "current implementation status":https://gitlab.freedesktop.org/lima/mesa/issues/39#note_79193 already allows the hardware acceleration of several tasks. GPU-based hardware acceleration is faster and less power hungry than software rendering, both by several orders of magnitude. It would allow Replicant devices to run applications with a performance close to that of non-free devices. *Hardware requirements* : A computer that is able to build Replicant. A Replicant device with a Mali-4xx GPU that can run mainline Linux (e.g. Galaxy S3 or Note 2). *Difficulty*: Medium *Requirements/Prerequisites*: "See with Lima project":https://gitlab.freedesktop.org/lima/web/wikis/home#build-and-install *Expected outcomes*: Lima driver being used for GLES rendering on a supported device. |_. Step |_. man-hours | | Rebase "Lima's Linux kernel DRM driver":https://gitlab.freedesktop.org/lima/linux on top of "forkbomb's Midas on Mainline kernel":https://blog.forkwhiletrue.me/pages/midas-mainline/. |>. 80 | | Replace mainline Mesa for "Lima's Mesa":https://gitlab.freedesktop.org/lima/mesa (with their driver). |>. 16 | | Build and test thoroughly with "synthetic":https://source.android.com/devices/graphics/testing and real applications. |>. 40 | | Create a fallback mechanism that uses the software renderer for GLES functions not yet implemented in Lima. |>. 100 | |_. TOTAL |_>. 236 | h3. Software Bill of Materials * "Replicant 9":https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9 * "Mesa":https://www.mesa3d.org/intro.html (in particular: "Gallium llvmpipe driver":https://www.mesa3d.org/llvmpipe.html) * "gbm_gralloc":https://osdn.net/projects/android-x86/scm/git/external-gbm_gralloc/summary * "drm-hwcomposer":https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer * "Linux kernel":https://www.kernel.org/ (in particular: drm/exynos driver and "vGEM driver":https://www.phoronix.com/scan.php?page=news_item&px=DRM-vGEM-Mesa-Software) * "SwiftShader":https://swiftshader.googlesource.com/SwiftShader * "Ne10 library":https://github.com/projectNe10/Ne10 * "Neon Intrinsics":https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics * "Lima":https://gitlab.freedesktop.org/lima h3. "Graphics acceleration on Replicant" nlnet Grant application |_. Project name | Graphics acceleration on Replicant | |_. Website / wiki | https://redmine.replicant.us/projects/replicant/wiki/Tasks_funding#Graphics-acceleration | Abstract: Can you explain the whole project and its expected outcome(s) in 1200 characters
Replicant is a fully free software Android distribution which is approved by the FSF. All supported devices on Replicant currently lack a free software driver for their GPU. As such, OpenGL ES (GLES) rendering must be done on the CPU through software rendering (SR). Replicant's current renderer is both incomplete and slow. It causes essential apps like web browsers to crash due to lack of GLES 2.0, and many other apps run too slow to be usable. This project aims to fix this by complementing Android's 9 graphics stack. Adding a few missing components will created of a fully-free, fast and compliant graphics stack. First we will write a gralloc (graphics memory allocator) tailored for SR that is compatible with drm-hwcomposer (a libre implementation of Android's Hardware Composer HAL). This gralloc enables drm-hwcomposer to work with SurfaceFlinger and SwiftShader, creating a stack capable of GLES 2.0 on the CPU of all Replicant devices. Afterwards we will integrate and optimize Mesa's llvmpipe SR, which offers better community support than SwiftShader. As last step we will add support for the Lima driver, which will bring an even faster GPU-backed GLES to at least 5 devices.|_. Have you been involved with projects or organizations relevant to this project before? And if so, can you tell us a bit about your contributions? | SEE TEMPLATE | |_. Requested Amount (Between 5000 and 50000 Euros) | 50000 Euros | |_. Does the project have other funding sources, both past and present? | SEE TEMPLATE | Explain what the requested budget will be used for?
The budget will only be used to fund this project through contract work. We estimate that this project should take 868 man-hours to reach full completion, with 632 man-hours being enough to reach all software rendering goals, leaving only the GPU rendering to be done. A detailed run-down of this estimate is available at https://redmine.replicant.us/projects/replicant/wiki/Tasks_funding#Graphics-acceleration So far we have a team of two people interested on working on this project (the two authors and submitters of this application). Both can commit to the project on a part-time regime (17.5 hours per week), which means that the project should be fully completed in about 6 months. We will make sure that everybody has a chance to apply for doing contract work. If we take the cost of a freelance developer in the USA (75 to 150 USD per hour) as a basis, to enable people living in Europe and the USA to apply, we can fund between 380 and 760 man-hours with the 50000 EUR budget. This should be enough to cover all work on software rendering plus the initial work on GPU rendering. As happens on all software projects, getting a precise time/effort evaluation is a difficult endeavour, specially when dealing with a project that is heavy on research such as this one. If the software rendering goals are not reached when the 50000 EUR budget runs out, or if the Replicant project deems it necessary to have GPU rendering, it will use its existing funds to pay for contract work if no volunteers are found to finish the project. The Replicant project will also make sure that the people working on this project have the necessary hardware to do it, for instance by shipping or reimbursing the purchase of a compatible smartphone with the Replicant project funds.Compare your own project with existing or historical efforts.
Past Replicant versions have relied on patches to the Android framework to make software rendering work. These patches were quite specific for Replicant and had no use elsewhere. This made them unfit for upstreaming or sharing with any other project. Android's Project Treble new graphics stack allows us to follow a different approach this time. Instead of patching the Android framework, we will implement one of the well defined Android HALs (Hardware Abstraction Layer): the gralloc HAL. The end result will be a software library that can prove to be useful on several projects besides Replicant (e.g. Android-x86 project) and thus fit for upstreaming. Furthermore, past Replicant versions relied on Google's software renderers (ligAGL and libpixelflinger) for OpenGL ES support. As quite a few other Google's open-source projects, these two had no community behind them and got stalled as soon as Google deprecated them. This time will we take a different approach. Although our first graphics stack will rely on Google's SwiftShader renderer, we will then move our efforts into Mesa. Mesa is a big community project, with hundreds of active contributors and great community support. It includes the llvmpipe software renderer along with new drivers in development for GPUs present on current and future Replicant devices. Mesa should provide a stable and maintained platform for years to come.What are significant technical challenges you expect to solve during the project, if any?
We expect to solve significant technical challenges during this project: 1. Implementation of the first Android gralloc library compatible with software rendering. 2. Development of free-software benchmarks for OpenGL ES on Android, used to test our optimizations to llvmpipe. 3. Optimization of llvmpipe by at least one order of magnitude. 4. Running an exynos based smartphone with fully free-software GPU graphics acceleration.Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?
This project will re-use code from several projects such as Android, drm-hwcomposer, Mesa and Lima driver. Whenever possible we will foster collaboration with these projects and submit our changes upstream. The Replicant project contributors and the FSF will supervise contractors to do the work. A blog post will announce that the Replicant project has got some funding for this specific task, and that it is looking for a contractor to work on it. This is to make sure that everyone has equal chances in the application process. Then the most suited contractor will be selected. Only contractors that already have worked on similar tasks as part of free and open source software projects will be chosen. This way we can look at their existing contributions and make sure that they are able to do the task before engaging with them. The Replicant project will also make sure that the contractor has or gets the hardware required to work on the task, before starting to work on it.|_. Attachments | SEE TEMPLATE |