Replicant

Since slowness is the problem with Mesa, is this bug solvable in a way besides using graphics hardware?

Or should the focus be on contributing to and integrating projects like Lima driver into Replicant?

It would be possible to complete the Android EGL implementation so that it is fully-featured and optimize it with NEON and ARM ASM code so that it becomes faster. There are also ways to improve things with hwcomposer and the framebuffer drivers and other per-hardware things.

But the real way to solve this is to have per-GPU free software implementations, such as Lima. Lima is not ready yet, but once it doesn't depend on the proprietary compiler and gets integrated in mesa, we'll certainly try and make it work with Replicant.

IMHO the Lima development stagnated since the last post, or are there any insider news?

I really want to take screenshots and the app alternative AndroSS:
https://f-droid.org/repository/browse/?fdfilter=screenshot&fdid=net.tedstein.AndroSS
doesn't work, too. (It takes screenshots, but the pictures are broken; looking like colored barcode art).

Does anybody knows a workaround for the screenshot feature (on Replicant), please?

IMHO the Lima development stagnated since the last post, or are there any insider news?

Quote: the tamil driver will see work whenever/ifever i am in the mood for working on it again

Does anybody knows a workaround for the screenshot feature (on Replicant), please?

Well, screenshots work on the browser, so maybe we should look how it's done there. I don't have time to work on graphics acceleration, as usual.

[I've removed the system browser, so I can't test that].

But I've found a functional workaround to make screenshots over ADB:
http://blog.shvetsov.com/2013/02/grab-android-screenshot-to-computer-via.html

IMHO the <incomplete EGL implementation> is an acute security related problem and will become a bigger one in the future.
The reason is, that I don't see another chance to get a more secure browser to work on Replicant without OpenGL ES, at the moment.
Please have a look at the discussion here: http://redmine.replicant.us/boards/39/topics/8007

• There would be a workaround for "Add support for more video software-decoding codecs, such as Theora" from the Tasks list, because with a working Firefox, I've successfully tested to run a .ogv (Theora) Video file out of the browser.
• This video was also switchable to fullscreen, so this could be another workaround for "Make the embedded video player in the browser work (or make it switch to fullscreen when playback starts)" on the Tasks list.
• You could delete "Write a modern Gallery application that doesn't rely on missing OpenGL features" from the Tasks list.
• Of course that would delete the EGL point itself "Improve the generic Android EGL implementation so that it implements all the currently missing features" from the Tasks list.
• The points above could be the some kind of workaround for "Make software video decoding work on Replicant 4.2" on the Tasks list, too.
• And last but not least, it (probably!) could lead to less battery consumption (http://redmine.replicant.us/boards/9/topics/7953) because there would be less (battery draining) software rendering, (but I have to test that first).

llvmpipe in Replicant 6.0 is currently based on Mesa 13.0.3. We use the Mesa sources from Android-x86 and they updated to Mesa 17.0.4: https://osdn.net/projects/android-x86/scm/git/external-mesa/commits?branch=marshmallow-x86
Unfortunately, it's not possible to merge their updates because they seem to rebase. We only need one additional patch, so it's better to switch to a new branch and adapt our patch on top of it. This breaks the current way of how branches are handled. In other repos, there is only one branch per Replicant release. For the Mesa repo, we'd need several branches to preserve the tags.

Maybe a naming scheme for the branches like replicant-6.0-mesa-13.0, replicant-6.0-mesa-17.0 could work.

Just a quick note: a new Mali-400 driver seems to be in very active development. It is far from complete, but passed a milestone on last week: it runs the kmscube successfully, so the whole stack basically works: https://github.com/yuq/mesa-lima/wiki

This GPU is used in Samsung i9100 and i9300, eventually others.

Some time ago someone gave me that link on IRC: https://www.mesa3d.org/perf.html that explains how to increase performances in MESA when using software rendering.

Niclas Hoyer posted a link a while ago to a new Mali-400 driver that still seems to be in very active development. They said that the whole stack basically worked back then, so I'd be curious to see how many bugs they still have left to fix. The link Niclas provided doesn't seem to be used anymore. You can find the links to the new active git repo here:

https://gitlab.freedesktop.org/lima
https://gitlab.freedesktop.org/lima/web/wikis/home

It was reported that a Note 2 developer got the Lima driver running on 4.9 mainline kernel: https://github.com/CustomROMs/android_local_manifests_i9300/issues/1#issuecomment-524013455

An ODROID user got the lima driver running on 5.3-rc3 kernel: https://forum.odroid.com/viewtopic.php?f=55&t=3691&sid=f73a6ad3052ead98bb90fa7854d061db&start=400#p264856

Lima kernel driver is now loading with hacks on Replicant 9 using 5.3.0-rc5+ kernel https://github.com/CustomROMs/android_local_manifests_i9300/issues/1#issuecomment-524375690

Here's a short video of Replicant 9 running Lima: http://www.belg.in/replicant_9.webm

Should the target version for this issue be moved to Replicant 9?

No. It should be kept on Replicant 6. The patch for switching between libagl and llvmpipe fixes this for Replicant 6. (Although Firefox based browsers will still be slow.)