too little usecases for Halium in pmOS

I think we should drop Halium support.

For me, it was always a trade-off between extending the lifetime "with not such much effort" of devices where this would otherwise be pretty much impossible (as mainlining all devices is not feasible), and between accepting that a hybris port has several downsides:

downstream kernel then for which we cannot provide security updates.
needs to use proprietary userspace components (android drivers)
needs to run parts of android side-by-side with the rest of postmarketOS

However, the "not so much effort" part does not play out as expected. We are far from "simply making a device work with libhybris", we don't have a single port where everything works. It is a lot of effort to integrate the missing libyhbris / Halium parts properly into postmarketOS, even just from the end of reviewing patches. Also the additional hybris related packages need to be maintained in the long term. All of these tasks consume time that I do not want to spend on it anymore (I spent many hours of reviewing hybris related code...), I'd rather spend the time to improve postmarketOS more effectively.

Also I'm amazed where we are now with the mainlining community. I'm mostly out-of-the-loop there, but seeing how many devices we have in community now with a close to mainline kernel is like a dream coming true. When postmarketOS started, this was completely out of reach. This is another reason to drop libhybris for me, let's double down on mainline. It won't work for all devices, but it's the better approach overall and much more worth spending time on in my opinion.

For people who love to work on libhybris stuff, I suggest to join forces with ubports. Or if it has to be postmarketOS related (because of Phosh or whatever), just create a new git repository where all the libyhbris related aports can live. Like Sxmo did it.

If you want to use pmbootstrap with a custom pmaports dir, with current .gitignore rules, it would work like this:

$ cd ~/code
$ mkdir -p pmaports-hybris
$ cd pmaports-hybris
$ git init .
$ cd ~/code/pmaports
$ ln -s ~/code/pmaports-hybris custom-hybris/hybris

By Oliver Smith on 2021-12-08T06:52:52

Speaking of UBports, I have since entering the Linux phone universe had the feeling that many of their struggles of weirdnesses and not being fully like an unlimited desktop linux (like e.g. with Wayland compatibility issues on devices without mesa support) are related to doubling down too much on libhybris/Android. Of course that's easy for me to say since I don't own a device that needs libhybris, intentionally so, but I feel like it'd definitely better for Linux on phones in the long run to abandon that hacky route.

By Ellie on 2020-07-30T11:42:44

Their main source of troubles always has been outdated software. Canonical dropped it with non-supported by anything Mir composer, 15.04 which would've become obsolete in a year, no app store, broken everything... That project should've been forgotten like Palm or WebOS, but UBPorts team did amazing job and Ubuntu Touch is awesome now. It's in polishing state now, you can't break anything easily in Lomiri/unity8, unlike Phosh which is breaking apart sometimes(but I believe that would be fixed soon since it's rapidly developing). Still, I don't think that Halium deserves do be dropped, it's an awesome option for non-mainlined devices

By Mark on 2020-07-30T11:42:44

I personally don't think forever-outdated-and-insecure-kernel is very useful for anything but toying around, for which I'm not sure it is worth the effort. So not sure I agree on the "awesome" part, I think it'd be better to get users onto devices that are safer for everyone. But that's obviously just my own opinion, and I can see how you and others would wildly disagree. Maybe a survey would be useful?

By Ellie on 2020-07-30T11:51:10

"get a new device" is not a solution IMO. I am pretty sure that survey among users is pretty useless, because all people want more features on their phones. Survey among developers is pretty useless too, because most people here like mainline too much. I agree that mainlining is better and more secure, but it may be not accomplishable for all devices.

By Mark on 2020-07-30T12:01:10

I got a PinePhone abandoning my MTK garbage, and I think more people should. Put your money where your mouth is, etc. And what's the alternative? A super outdated kernel alike to a Win95 machine connected to modern internet and hoping it doesn't get hacked? That doesn't seem like a solution to me either. At some point IMHO one should accept not everything is worth salvaging at all cost.

By Ellie on 2020-07-30T12:24:16

abandoning my MTK garbage

Time to recycle it using postmarketOS ;)

By Dolphin von Chips on 2020-07-30T15:44:15

Come on, 4.14, 4.9 and even 3.10 kernels are not that outdated. And we aim for extending the lifecycle of the device, and if Halium is one way to do it, we should consider it too. And PP isn't good enough, even msm8916 is more powerful than it, so why "outdated" msm8994 should not get Phosh and other things and absolutely-not-outdated PP should? Just because of kernel version?

By Mark on 2020-07-30T15:55:08

A patched 3.10 kernel is fine. An unpatched one is a disaster.

so why "outdated" msm8994 should not get Phosh and other things and absolutely-not-outdated PP should? Just because of kernel version?

If you want to use the device for serious work or private communication, I would highly suggest yes. Unpatched kernel is pretty bad, it has new security holes found all the time, some of them remote exploitable.

@DolphinChips there is a linux provided for it... via halium/unpatched kernel. Doesn't make sense for me, outside of the narrow cases (e.g. always-offline device, or just for experimenting around with no sensitive personal data on it. but I'd rather not use an additional device just for that)

By Ellie on 2020-07-30T16:23:06

Come on, 4.14, 4.9 and even 3.10 kernels are not that outdated

@nergzd723 Come on, remember #579 (closed) , !479 (merged) : old kernels cannot run some modern Linux userspace at all, and Halium will not save them. Just some missing syscalls on old kernels, and boom, you can't run postmarketOS on them. At least some apps for now, but in future situation will only be worse. Your only chances are backport patches, rebase on newer kernel version, or mainline.

Doing downstream kernel adaptation (be it with Halium or not) which will be broken in a year with a next weston, pulseaudio or lxc update - this is a path leading to nowhere. This is a dead end.

Sure, you can easily do it in UBPorts or Sailfish, who don't care about security and updating their software, from kernels to userspace libs. If you want to run Halium hw adaptation, go there; Halium was literally created for UBPorts, libhybris was (literally) created for Sailfish, it works good and is well integrated there.

But if you want to run normal modern Linux userspace, you just can't do it on downstream kernels. At all. period.

By Alexey Min on 2020-07-30T17:03:57

I'm afaid of fate of non-mainlineable devices. Snapdragon S1, old Marvell/BCM platforms, MTK... There are high chances that these devices would never be mainlined. And with Halium, we can make some things work on them to not make them completely unusable(ofc not Snapdragon S1 :D). Hacky halium road could help extending device list with "good" support(can run mobile UI's).

By Mark on 2020-07-30T11:37:59

just create a new git repository where all the libyhbris related aports can live. Like Sxmo did it.

@nergzd723: isn't that the perfect solution to this problem? Then people who actually want to run hybris on pmOS can develop quickly, without needing to wait for code review from developers not interested in hybris. And we have freed up resources by dropping the hybris stuff from this repository.

CC: @danct12

By Oliver Smith on 2020-07-30T16:15:03

no... that way it definitely won't get popular... and we don't have enough people, if we at least had 3 active maintainers for Halium, maybe that'd be a good solution, but ATM I'm the only interested in Halium(Alexey Min and Danct are quite dormant, and NotKit is not interested anymore)

By Mark on 2020-07-30T16:20:36

I'd argue that if having not enough people interested is a reason not to put it in a separate repository, then it really shouldn't be part of pmaports!

Any way, unless those new maintainers spring up, hybris is basically useless (AFAIK). I believe it only allows for X11 on hwcomposer currently, and maybe sound. To allow for more support, we would need to fork quite some packages, on edge, and that's just maintenance heavy.

Also, do note that the devices using hybris are not getting into community (as any downstream device). If you add that halium is not properly integrated into pmOS, that building libhybris is currently unreliable, and that it encourages non-free software (Halium's purpose is to reuse Android binary blobs), then you have a pretty bad situation overall.

By Antoine Fontaine on 2020-07-30T23:07:51

Even !1463 (closed) is enough to make it useful: you can run Phosh with hwcomposer! I do agree that it's maintenance-heavy however... You know why I want it to become popular? It will make devices with downstream kernel useful. Not all 171 of them(grep -r downstreamkernel_prepare | wc -l), but at least 43(counted manually, referencing this https://github.com/Halium/halium-devices/tree/halium-7.1/manifests and our pmaports) can do Phosh using Halium, but only 12 devices run mainline!(grep -r "Close to mainline" | wc -l)

By Mark on 2020-07-31T09:52:55

added discussion + 1 deleted label

Sorry @nergzd723, but since nobody is willing to put in the effort to maintain this properly, it has to go.

It is failing to build for armhf too and I want to get down to 0 failing packages today. Instead of adding !armhf everywhere, I might as well just remove it now.

Wiki page updated with a pointer to this issue, and to link to the last version of the hybris pmaports: https://wiki.postmarketos.org/wiki/Hybris

By Oliver Smith on 2020-08-03T07:57:25

closed with commit e1a3324e

mentioned in merge request !1463 (closed)

By Oliver Smith on 2020-08-03T08:18:51

mentioned in merge request !1462 (closed)

By Oliver Smith on 2020-08-03T08:19:27

mentioned in merge request !1144 (closed)

By Oliver Smith on 2020-08-03T08:22:45

mentioned in commit e1a3324e

By Oliver Smith on 2020-08-04T10:20:02

mentioned in commit 334c75da

By Oliver Smith on 2020-09-02T13:52:10

mentioned in commit c9fa4ab5

By Oliver Smith on 2020-09-02T13:56:14

mentioned in commit 0520275b

By Oliver Smith on 2020-09-10T11:54:12

Wouldn't a big use case of halium be the variety of Mediateks with proprietary GPUs around? This seems to be their only hope of being usable in postmarketOS in the short term, and would probably encourage mainlining in the long term as well...

By Raffaele on 2021-05-28T16:33:26

mentioned in issue #1316 (closed)

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

marked the checklist item drop Halium support as completed

By Newbyte on 2023-02-01T08:34:39

too little usecases for Halium in pmOS

Child items 0

Activity