RFC: how to deal with default camera apps?

As I understand it, we're in the unfortunate situation that there are two camera apps made specifically for one or more devices, with little/no overlap. For example, Megapixels is required for the pinephone family. Millipixels (Megapixels fork) is required for the camera on the Librem 5. One won't work with the camera(s) on the devices supported by the other.

The problem I'd like to solve is that the camera on the Librem 5 does not work out of the box when installing a UI like phosh, so I'd like it to work out of the box by installing the correct camera app. Currently in pmaports, we have megapixels in the pmb_recommends, which causes it to get installed on all phosh images, even for devices with no working camera. On the Librem 5, megapixels doesn't work at all, so it's even worse: we pre-install an app that we know won't work for that device. To fix this, a user has to manually replace it.

I think at the very least, we should remove megapixels from pmb_recommends in UI packages. Devices that need megapixels can depend on it in some $device-$ui subpackage (e.g. device-pinephone-phosh). This is one way to solve the problem... but it has some downsides, mainly that the dependency on the camera app is pushed to the device packages. But this seems like the "correct" way to handle this... thoughts?

I submitted millipixels to aports, but the question was raised about using "provides" (@psykose isn't wrong to object, technically they aren't the "same"... ) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43318 However, using "provides" would allow us to depend on "megapixels" in the UI package, and then add exceptions in device packages by depending on something else that "provides" megapixels (e.g. millipixels).

I'm filing hoping someone else has some better ideas on how to handle this in pmaports/pmOS, let me know!

I asked this question myself already: Why is Megapixels installed on all devices when camera is not even supported? Example: SDM845 devices.

So I'm giving a +1 to remove it from pmb_recommends from the UI packages. Maybe you can have a postmarketos-ui-camera package on which device packages with support for camera can depend on? Depending on the device, the postmarketos-ui-camera 'provides' the right app. Not sure if this is possible though in practice.

By Dylan Van Assche on 2023-01-18T19:00:51

yeah I think this would be a virtual package, and each device package would have a subpackage that 1) depends on the appropriate camera app for the device, and 2) provides=postmarketos-ui-camera. This is kinda what we do with osk-sdl/unl0kr and the pmos-fde virtual package.

By clayton craft on 2023-01-18T19:00:51

but it's tricky to get right, imho... like we don't want apk installing the wrong camera app, and I'm not sure how you'd set provider priorities in this situation where you have multiple device-camera subpackages all providing the same virt. package, and ensure you always get the right one for a device.

imho the most straight forward option is just have a depends=millipixels for the device-purism-librem5-phosh, depends=megapixels for PP/PPP-phosh, and so on (each of those with an install_if to be pulled in by installing phosh, etc on the device)

By clayton craft on 2023-01-18T19:03:17

since they are not compatible implementations, the provides/priority is indeed not what you want (if you think about it, provides= is never correct where an "alternative" can be wrongly provided and not be useful entirely at a device level, like here)- the install_if can do exactly what you want though by automatically pulling something in based on the installed condition.

By psykose on 2023-01-18T19:16:40

There are many issues with having device packages depend on a specific camera app (or even just "recommend" it). Firstly, it means UIs don't have control over the camera experience in the user interface. This is a moot point right now since even though e.g. Plasma Mobile has its own camera app, it doesn't work right now, but in the future I would hope that we've resolve this camera mess and have some standard interface camera app developers can target.

A more relevant issue given the status quo is UIs like "console" and "none". We don't want to install a camera app on these, and how do we prevent that from happening if we use the device package to pull in the camera app?

Then there's also the problem of that people then can't remove the camera app if they don't want it for whatever reason (which only exacerbates the previous two points) if it's listed in depends.

By Newbyte on 2023-01-19T12:36:44

you use a subpackage, like i explained earlier

...

On January 19, 2023 4:35:56 AM PST, "Newbyte (@Newbyte)" gitlab@mg.gitlab.com wrote:

Newbyte commented on a discussion: #1912 (comment 1245762421)

There are many issues with having device packages depend on a specific camera app (or even just "recommend" it). Firstly, it means UIs don't have control over the camera experience in the user interface. This is a moot point right now since even though e.g. Plasma Mobile has its own camera app, it doesn't work right now, but in the future I would hope that we've resolve this camera mess and have some standard interface camera app developers can target.

A more relevant issue given the status quo is UIs like "console" and "none". We don't want to install a camera app on these, and how do we prevent that from happening if we use the device package to pull in the camera app?

Then there's also the problem of that people then can't remove the camera app if they don't want it for whatever reason (which only exacerbates the previous two points).

-- Reply to this email directly or view it on GitLab: #1912 (comment 1245762421) You're receiving this email because of your account on gitlab.com.

By clayton craft on 2023-01-19T16:09:35

Devices that need megapixels can depend on it in some $device-$ui subpackage (e.g. device-pinephone-phosh). This is one way to solve the problem... but it has some downsides, mainly that the dependency on the camera app is pushed to the device packages.

i don't use these myself, but is this not the entire point of the device packages, to depend on things for that device? so, the camera app that actually works on the device is depended on. this seems like an upside rather than a downside, as the device package pulls in the correct dependency for support of the device thingie.

By psykose on 2023-01-18T18:54:31

yes, this is what device packages are for. BUT this currently uses a pmOS-specific construct.. pmb_recommends, which allows installing things as if they were dependencies by default, but without the depends constraint so that users can manually remove them if they want.

So by moving to device packages depends, it's no longer an optional thing for users to have, they won't be able to remove it. That's the trade-off, and why I thought this warranted some further discussion. IMHO, we should just move to device packages and have a hard dependency for a device on a camera app that works with it, for UIs where folks would expect a camera app to be available.

By clayton craft on 2023-01-18T18:54:31

sure, that makes sense.

BUT this currently uses a pmOS-specific construct.. pmb_recommends

curious- how does this work? apk doesn't have this sort of recommend thing with optional removal/opt-out (think apt recommends, etc), and i didn't check how this is implemented

By psykose on 2023-01-18T18:57:13

it's used by pmbootstrap when building an image, but ignored by apk and everything else at runtime.

pmbootstrap parses the apkbuild, appends any pmb_recommends to the list of package it will install in the image, but since they aren't listed in any depends=, it's as if the user manually apk add-ed them, so they can be removed manually later by the user if they don't want it. It allows us to build an image with some useful defaults included, but gives users some power to remove some of those that they don't actually want.

By clayton craft on 2023-01-18T18:59:09

it's as if the user manually apk add-ed them

ah, so a default world set. makes perfect sense, i know exactly how that works then :) thank you!

By psykose on 2023-01-18T19:01:19

However, using "provides" would allow us to depend on "megapixels" in the UI package, and then add exceptions in device packages by depending on something else that "provides" megapixels (e.g. millipixels).

this strictly just seems like "we put megapixels first in depends= and now that there is a second(*) camera app for a different set of devices we need to virtualise this somewhat"

if the goal is for ui packages to pull in a camera (always), then depend on the camera they will support in the ui app depends=- every one can have depends=megapixels, depends=millipixels, .. depending on which one works. and since they don't conflict (read: the files are different) people can install the other if something magically changes overnight, but in general editing the dependencies here is just a few minutes of work if really needed. no need to complicate it with any providers :)

*: .o0(this millipixels thing is an entire megapixels fork just to support one device? how strange, i've always found things a bit weird in this mobile space, especially with all the various UI forks, etc, instead of something aimed to work universally. certainly doesn't make it easier...)

By psykose on 2023-01-18T18:57:02

*: .o0(this millipixels thing is an entire megapixels fork just to support one device? how strange, i've always found things a bit weird in this mobile space, especially with all the various UI forks, etc, instead of something aimed to work universally. certainly doesn't make it easier...)

Yes, kinda. It's diverged a bit from megapixels, e.g. using libcamera. And in theory it could support other devices if someone does the work. The fork wasn't made by any pmOS folks. I hope that millipixels goes away some day and it's merged back in with megapixels, but that day doesn't seem to be happening any time soon... so here we are.

Also see: https://source.puri.sm/Librem5/millipixels/-/issues/48

By clayton craft on 2023-01-18T18:57:02

It's diverged a bit from megapixels, e.g. using libcamera.

ah, okay, makes sense. seems people are using this more these days, hopefully it (libcamera) gets to some good places :)

The fork wasn't made by any pmOS folks. I hope that millipixels goes away some day and it's merged back in with megapixels, but that day doesn't seem to be happening any time soon... so here we are.

no worries, just a passing observation. afaict megapixels was mostly the work of martijn and seems to have been designed to be an open linux camera app, so it surprises me that instead of making it better others forked it just to initially start out with one device, you know..

By psykose on 2023-01-18T18:59:55

Yeah, you're not the only one with those feelings

By clayton craft on 2023-01-18T19:03:49

added discussion label

The ideal solution is for Millipixels to merge it's libcamera support back into Megapixels, so Megapixels itself can be used on the L5. Even more ideal would be for devices like the PinePhone to also get libcamera support, and gstreamer to get a libcamera backend so alternative camera apps like Plasma Camera can also be used and we don't have to force any particular camera app on the user.

But we don't live in an ideal world, so we have to make do with alternative solutions. I agree with the messages here that this is an ideal use-case for the device package. It's -phosh and -plasma-mobile subpackages can (and should) install the right camera app out of the box, at least as long as no app works on whatever device we put it on.

By Bart Ribbers on 2023-01-20T06:12:46

The ideal solution is for Millipixels to merge it's libcamera support back into Megapixels, so Megapixels itself can be used on the L5. Even more ideal would be for devices like the PinePhone to also get libcamera support, and gstreamer to get a libcamera backend so alternative camera apps like Plasma Camera can also be used and we don't have to force any particular camera app on the user.

Yeah, I agree 100%, but I'm not capable of making any of that a reality

By clayton craft on 2023-01-20T21:30:13

mentioned in commit 27b54442

By clayton craft on 2023-01-21T22:00:52

mentioned in merge request !3815 (closed)

By clayton craft on 2023-01-21T22:01:55

mentioned in commit 788a998e

By clayton craft on 2023-01-21T23:13:25

mentioned in commit 87757007

By clayton craft on 2023-01-25T21:00:09

mentioned in commit 23c39003

By clayton craft on 2023-01-29T06:25:23

mentioned in commit b4e8fa8f

By clayton craft on 2023-01-29T17:37:08

mentioned in commit a4c43db8

By clayton craft on 2023-01-29T17:42:17

mentioned in commit 831d793c

By clayton craft on 2023-01-29T17:48:12

mentioned in commit bf8b16f6

By clayton craft on 2023-02-01T07:18:08

mentioned in commit 6ab54813

By clayton craft on 2023-02-12T19:55:16

mentioned in commit 4160966b

By clayton craft on 2023-02-12T19:59:00

mentioned in commit a5997589

By clayton craft on 2023-02-27T20:13:46

mentioned in commit e903bfd3

By clayton craft on 2023-02-28T18:18:36

mentioned in commit d6fb5635

By clayton craft on 2023-02-28T20:51:49

mentioned in commit 4f790fb8

By clayton craft on 2023-03-01T07:43:13

closed with commit 4f790fb8