Embrace PowerVR or not?

By Oliver Smith on 2021-11-27T11:57:32

What about having a separate "pvrports" repo that can be added to these devices that provide these packages? It wouldn't necessarily have to be provided by postmarketOS. It would solve the problem of packaging non-free userspace stuff in the main repo, and it could have its own wlroots and all without affecting the main repo. But I suppose this only begs the question whether devices depending on a potentially third-party repo should be accepted into community.

By Newbyte on 2021-11-27T12:13:14

What about having a separate "pvrports" repo that can be added to these devices that provide these packages? It wouldn't necessarily have to be provided by postmarketOS. It would solve the problem of packaging non-free userspace stuff in the main repo, and it could have its own wlroots and all without affecting the main repo.

I think if there was a third party repo for these hacks that is separately maintained (with people stepping up to maintain it, take care of issues and merge request, set up a bpo instance or similar to build the packages), it would be a nice solution actually. I think that's what https://gitlab.com/hybrisos tried to do, but didn't follow through.

But I suppose this only begs the question whether devices depending on a potentially third-party repo should be accepted into community.

I'd not mark such devices as postmarketOS community devices, but they could be in the pmOS wiki, and have a separate device category for "supported by pvrports" or something.

(But not saying this is the best way forward, just brainstorming here.)

By Oliver Smith on 2021-11-27T12:15:37

I like @Newbyte suggestion. I'm not really a fan of these closed source blobs here. People who have issues with such devices will create issues in this Gitlab repo or ask for help on Matrix. If we have a separate thing, they can ask about these out-of-tree devices on the help channels of the separate thing.

By Dylan Van Assche on 2021-11-27T12:23:04

changed milestone to %v22.06 Release

Well the main concern seems to be the maintainance of these hacks right? Well currently I'll try to maintain the wlroots and mesa. Also it wont be affecting the other users so I dont see the problem there. The other options are to just drop it or we host the pvr stuff ourselves (which doesnt make an easy user experience)

By Mighty on 2021-11-27T12:11:33

mentioned in merge request !2702 (merged)

By Jonathan Bakker on 2021-11-27T17:09:43

We should avoid the adding extra burden on the maintainers for device specific hacks. To me it sounds like keeping the pvr hacks in a separate repo is the best solution for now. If we ever get pvr working with upstream mesa the issue naturally disappears. And if any of the pvr using devices are usable enough, they will get the attention needed to fix the issues upstream, if not, their support will just bitrot away eventually

To me it seems that adding the extra repo to the device can be done by some device specific package?

By Tony Lindgren on 2021-12-01T10:05:32

Yeah, these were my thoughts as well. I think it would be nice if the device packages and all still could be in pmaports and they just add that extra repo as part of the build process. I get that there's the question about how we are supposed to support blobs, but I think it remains to be seen if this actually will be a problem. I don't particularly think it's reasonable for the maintainers of PowerVR devices to set up their own instance of nearly all postmarketOS infrastructure, but another repo shouldn't be too hard I think.

By Newbyte on 2021-12-01T10:05:32

should we remove the powervr blobs from the repo?

Probably yes to this point, for others I have no opinion.

By Alexey Min on 2021-12-12T13:00:47

mentioned in issue #1135 (closed)

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

mentioned in issue wiki#65 (closed)

By Antoni Aloy Torrens on 2022-01-08T18:27:02

If there is no v21.12 release for the espresso3g, I think it would make more sense for new pmOS users to group it separately from the other devices which have one. I went into more detail on wiki#65 (closed).

By UltrasonicMadness on 2022-01-09T12:35:03

@MightyM17 We discussed this in our team meeting, and ultimately decided that supporting pvr in pmaports/pmOS has many of the same problems that we saw when trying to support hallium/libhybris[1], something we decided against. For much of the same reasons, we've decided that we want to avoid adding the proprietary userspace components required to support pvr in pmOS.

Supporting a proprietary userspace means maintaining a lot of forked packages with out-of-tree patches. Maintaining these forked packages requires effort (keeping in sync with upstream, rebasing), and can also cause issues/noise for upstream (wlroots, mesa, etc) when they receive bug reports from users running these unsupported/unaccepted patches. These forked packages can/do also expose issues in Alpine's package manager (see current issues with wlroots-sxmo on Alpine, and past issues with mesa-git here in pmaports...). It's hard to get it right and causes big problems if, for example, apk decides to replace wlroots with wlroots-pvr on a desktop system.

This decision does not mean that the espresso3g has to be removed from the "community" device category, if you're still willing to maintain it. We can also look at adding support for the device in an upcoming v21.12 service pack (like how the N900 was re-introduced in 21.12 SP1). We don't want your excellent work on supporting this device to go unnoticed :)

reasoning for dropping libhybris support: #703 (comment 388155296)

By clayton craft on 2022-01-25T20:32:51

closed

mentioned in merge request !3027 (merged)

By Mighty on 2022-03-24T09:40:43

mentioned in issue #932 (closed)

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

I don't think you can really apply the same reasoning to pvr than libhybris.

Sure, of course the behind the scene logic is similar, but the scale (what else would you need after !2573 (closed)?) and the upfront reasons seem different.

For all its selling points, Halium doesn't live up to them.. and even if it did, it's not like the android blobs are seamless or perfect either. So you'd be investing manpower, into what? Something very device-specific and with very little foreseeable practical usage? The most I could see given it's 2022 and not 2017 (i.e. most open drivers are totally viable) is some quick comparison/benchmark with the mainline solution, but dual booting could even be better for that.

Here instead you have the antichrist of openness, that actually has no alternative in sight. It's not just that you'd be roundabout endorsing a proprietary userspace.. this is even the only userspace available. And IANAD, but if I were to actually want to start making something better out it, this would be the perfect environment to start some toying/RE (plus it seems a bit reductive not to celebrate the progress that openpvrsgx already is).

By mirh on 2022-03-27T15:38:04

While I agree with you to some degree, even just having a patched wlroots is kind of a pain to maintain. wlroots neither has a stable ABI nor API, and some compositors aren't playing catchup fast enough (prominently Phoc), so you'd have to have multiple patched wlroots packages just like we have multiple wlroots packages in Alpine (soon 3 probably). The myriad of apk bugs that come into play when doing something like this don't make the situation better. If you are willing to maintain these things and fix apk maybe it can be reconsidered, but as it is right now I don't think this is viable for pmOS.

Furthermore, as compositors evolve, I think it's only likely that more and more of them will require extensions that this proprietary driver does not provide, which potentially results in even more effort to maintain this.

By Newbyte on 2022-03-27T15:40:00

From a distro packaging/maintaining perspective (pmOS is a distro afterall..), they are very similar. The specifics of what hybris vs pvr are is not important here, the point is that there would need to be forked packages in the repos, and we have a very poor history with trying to support this in the past. See my previous comment on the matter. Newbyte or or less nailed it too.

By clayton craft on 2022-03-27T17:54:59

Pretty duper honestly, I believe that if you still have a powervr device today (even if it's the most consumer galaxy nexus out there).. you probably can handle whatever small hoop every now and then.

I mean, I get the absolute peace of mind of just installing the thing and calling it a day, but at least the pal of mine with a N900 would rather loose 5 extra minutes to have gpu acceleration working, than not (I mean, not because he totally needs it, but because that kinda makes the difference between a paperweight with basically just academical interest and something with the legit pretence to be useful even day-to-day)

But I'll grant I don't really know what kind of technical hurdles we are actually talking about. I'm just imaging.. this cannot be worse than when I used to run fglrx (on the last kernels nonetheless!) on my manjaro laptop?

By mirh on 2022-03-28T00:21:35

yeah you don't know the issues we had with packaging forks, and fighting with apk. it often resulted in breaking things for other devices/installs, because the forked package would get installed despite all attempts to only have it installed in specific situations. and I have 0 confidence that we would be able to do it again without hitting those same issues, again.

By clayton craft on 2022-03-28T04:58:48

What could even go wrong with a separate wlroots-pvr package (and which wouldn't be referenced anywhere else)?

Assuming we aren't talking about the most blatant scenario of "dumb user decides it's time to blow up its system".

By mirh on 2022-03-28T01:52:49

for example, apk will often pick the wlroots-pvr package when satisfying the dependency wlroots. so you have some package that depends on wlroots on the pinephone (for example) and then apk might install wlroots-pvr when it absolutely should not. there's no way we've found to reliably tell apk "only install wlroots-pvr in this one specific condition, and only then". The priorities and so on in apkbuild's spec don't seem to work reliably all the time, or something

another problem we had when trying this in the past with other libraries was the -dev package for the fork being installed when the original should have been, breaking compilation and/or causing all sorts of other weird dependency/packaging/installation issues.

By clayton craft on 2022-03-28T03:43:08

Just to clarify, with the recent changes done in the maemo-leste mesa and sgx-ddk-um git trees, wlroots now only needs an updated version of the GL_EXT_unpack_subimage patch done by Jonathan Bakker. I've been meaning to send a pull request for the wlroots folks to review, seems it should be possible to merge it now with the surrounding issues sorted out.

Links below for the git trees maemo-leste is using for reference:

https://github.com/tmlind/linux_openpvrsgx/tree/droid4-pending-pvr-omapdrm-v5.16
https://github.com/freemangordon/mesa/tree/mesa-pvr-ti
https://github.com/maemo-leste/sgx-ddk-um
https://github.com/tmlind/wlroots/tree/missing-unpack-subimage

Anyways, so the packaging issue now ends up being the custom mesa patches, not sure if that's any easier.

By Tony Lindgren on 2022-03-28T11:35:24

Anyways, so the packaging issue now ends up being the custom mesa patches, not sure if that's any easier.

nope. in fact, trying to maintain a different mesa package (it was called 'mesa-git') was one of the failures that motivated our decision to not support this.

By clayton craft on 2022-03-28T17:54:40

@mirh thanks for the solidarity. do you have a PowerVR device?

The idea @MightyM17 and myself have is: drop PowerVR from pmOS, so that the devices can qualify to remain in pmOS' community category. Other than the PowerVR issue, the OMAP SoCs generally have the best mainline support of any other in the ARM world (a quick check in pmaports shows that N900 and now espresso are the only phones that currently use vanilla kernels straight from kernel.org). Thus keeping them 'visible' in community is a reasonable goal. Besides the misfortune of the PowerVR SGX, the only additional downside of these SoCs is age/performance.

As for PowerVR, the idea is to continue supporting it for as long as possible, outside pmOS. This will leverage on the work and experience from other communities that actively support these devices, such as the openpvrsgx project, and Maemo Leste. @MightyM17 will be working on this, and I will too. You can also join if you have a compatible device :-)

By Sicelo on 2023-08-21T08:50:37

If remaining in the community category is kinda this element of pride, I get why you still wouldn't ship the blobs out of the box. But I'm not exactly sure what the obstacle for an "optional" package would be.

Maybe you don't have such a polished tool like mhwd for the switching, but if it's just one package (for as much as important as the compositor) certainly it can't be that difficult? Even just a random package that you have to manually install from CLI?

Then, the only powervr thing I have available atm is a ps vita I guess (which is linux enabled FIY), but I was just having such concerns because it would be kinda the flex to finally be able to say "linux supports everything that X does".

By mirh on 2022-03-28T04:55:49

Relevant: #1481

By Newbyte on 2022-03-30T10:48:48

mentioned in issue #1433 (closed)

By Mighty on 2022-04-06T16:39:05

mentioned in issue #2662 (closed)

By Sicelo on 2024-03-16T15:22:22

Embrace PowerVR or not?

Child items 0

Activity