PowerVR blobs for droid 4/n900 (motorola-maserati, nokia-n900)

So, the biggest issue I see with this is that we'll re-open the mesa-git packaging fiasco (eg #642 (closed)). The other option is to have a patched mesa that gets installed for all devices. It should be possible to make Mesa co-exist with the PowerVR patches - they're basically just a new DRI driver with a couple of other minor changes that can be conditionally used.

Prior to my investigations with Mesa, I had an APKBUILD which used the glibc-mesa parts (GL loader, etc) located at https://gitlab.com/xc-racer99/pmaports/-/tree/sgx-v2 which uses a post-install/post-upgrade script to make the necessary modifications to the blobs (they use fnctl64, which isn't available/stubbed to fnctl in musl). For the distribution of the required binary blobs, they unfortunately need some binary modifications for musl compatibility. Due to the license of the blobs, they can't be distributed in a modified state, hence the post-install script. I don't believe these are necessary since we can now build Mesa without them, but I'm not 100% sure.

I have a working (as in building) APKBUILD for "mesa-pvr" at https://gitlab.com/xc-racer99/pmaports/-/tree/sgx-v3 with some untested sgx-ddk-um blobs. In order to have multiple installed, I do have subpackages for making one a default which modifies the linker paths (a little bit ugly, I know). Most of this is currently untested from the APKBUILD as I've set things up manually locally. There's definitely some conflicts between the mesa-pvr and regular mesa in the APKBUILDs.

By Jonathan Bakker on 2021-01-04T02:35:07

Also, here's the status of what I've found for what DEs work (note that I've been using the ti443x/droid4 blobs modified for s5pv210 on a first-gen Galaxy S device). This is with my WIP mesa patches, not with the blobs as they were provided by TI.

sway

works
Needs a patch to wlroots (attached) - this is to work around the missing GL_EXT_unpack_subimage extension, and also a change to make it CLAMP_TO_EDGE (reason unknown right now)

phosh

works, but still seems incredibly slow (ie not accelerated, though the wlroots part is)
Needs a patch to wlroots (attached) - this is to work around the missing GL_EXT_unpack_subimage extension, and also a change to make it CLAMP_TO_EDGE (reason unknown right now)

plasma mobile

works, seems relatively snappy for a 10 year old phone when not crashing due to OOM conditions

X11-based

not working, I've tried xfce4 but the blobs are missing an extension (GL_OES_texture_border_clamp) required by glamor for modesetting plus according to the Maemo guys there's other issues with gles2 and glamor/modesetting.

0001-render-Don-t-use-GL_EXT_unpack_subimage-when-not-ava.patch

By Jonathan Bakker on 2021-09-28T12:54:28

FYI, I just posted an updated version of Jonathan's wlroots patch and few other fixes https://github.com/tmlind/wlroots/commits/pvr-gles2

At least weston-simple-egl issue remains compared to wlroots-0.14.1 caused by commit 4e07d4cbf9c1. This is because current wlroots no longer uses EGL_WL_bind_wayland_display, instead weston-simple-egl tries to use dmabuf and it currently fails for some reason.

I also pushed out a branch for wlroots-0.14.0 to https://github.com/tmlind/wlroots/commits/pvr-gles2-0.14.1

Note that if compiling wlroots with distro mesa, HAS_GBM_BO_GET_FD_FOR_PLANE needs to be disabled in wlroots code.

By Tony Lindgren on 2021-09-01T12:17:22

Ok, I've pushed an updated copy with the correct "provides" for mesa-pvr. Unfortunately, it is still blocked by https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1867 from what I can tell - eg mesa-gl would be selected instead of mesa-pvr-gl even when mesa-pvr is selected.

By Jonathan Bakker on 2021-01-04T02:59:04

added category::device discussion + 1 deleted label

Great work, @xc-racer99!

Regarding the problems with a second mesa package... I think the easiest way to work around all the problems would be installing mesa-pvr* in addition to mesa*, and just making sure that mesa-pvr* overrides all files from mesa* with replaces and install_if. The downside is, that devices using mesa-pvr will download both packages (and subpackages). But the upside is, that they will only extract the files from mesa-pvr* and we can sidestep all the potential problems.

In detail, this would work as follows:

add replaces="mesa" to the APKBUILD (main package)
for each subpackage:
- add replaces="mesa-gl" to mesa-pvr-gl and so on
- add install_if="$pkgname=$pkgver-r$pkgrel mesa-gl to mesa-pvr-gl and so on
let relevant devices depend on mesa-pvr

(This is of course not the proper way, but given that we had all these problems before, this seems the most feasible solution to me right now.)

By Oliver Smith on 2021-01-05T03:36:47

Ok, that sounds like it could work. I was thinking of modifying the package selection logic in pmbootstrap and adding another step before picking the shortest package name - checking if the parent package (ie origin in the .PKGINFO if you extract the .apk file) is due to be installed. That should catch this particular case, while still not installing mesa-pvr when only plain mesa has been requested. Hopefully it doesn't break anything, are than any situations you can think of that it might?

By Jonathan Bakker on 2021-01-05T03:36:47

mentioned in issue #262 (closed)

By Sicelo on 2021-01-07T23:13:24

added device-nokia-n900 label

mentioned in merge request !2553 (merged)

By Mighty on 2021-09-29T17:18:58

mentioned in issue #1135 (closed)

By Sicelo on 2022-01-08T17:07:23

Closing this as we decided to not embrace PowerVR in #1316 (closed).

By Newbyte on 2022-03-27T08:29:36

closed

PowerVR blobs for droid 4/n900 (motorola-maserati, nokia-n900)

Child items 0

Activity