Snapshot1 is a new camera app from GNOME. It uses PipeWire for accessing cameras, and can as such support a wide range of cameras without needing device-specific code. In addition to this, I personally find the UX to be superior to Megapixels. So far we've confirmed that it works on PinePhone Pro and the original PinePhone — I will try the Librem 5 later.
"Get it working on" TODO:
Librem 5
Nokia N900? (don't think Megapixels works with it anyway)
Pinebook Pro? (don't think Megapixels works with it anyway)
@Tooniis Do you think you could test it on xiaomi-scorpio? While it's unlikely it would work with the libcamera backend there for obvious reasons, PipeWire has a V4L2 backend that somehow works on my PinePhone Pro. Maybe the same could work on xiaomi-scorpio?
For the original PinePhone, as of v46.3 (2024-05-06), Snapshot has these bugs / deficiencies compared to Megapixels:
The captured images are 1080x1280 even though the camera supports 2592x1944.
No postprocessing script support. This includes both the program having the ability to run such a script, and the program having the ability to automatically take multiple pictures in succession as inputs for that script.
Autofocus doesn't seem to be activating. It didn't always activate by default in Megapixels either, but it could be forced to activate manually by tapping the preview.
The preview of the cameras updates very slowly, at 1fps or less. Often it freezes entirely and even crashes pipewire process itself. Possibly because the current libcamera fork in pmaports forces the use of software ISP, because the front camera doesn't work well with the hardware ISP. (The rear camera supposedly works fine but the choice of ISP is currently made at the device level rather than camera level.)
I edited it to be clearer. My intent was to label them as Snapshot vs not-Snapshot issues, ie whether we can expect them to be fixed just by a new Snapshot release or not.
Edit: oh, sorry, I read that wrong - if 3. is fixed that implies the patch is already used. As I'm not able to reproduce this issue on a Pinephone Pro here - where the rotation should be handled exactly the same - I wanted to quickly ask: was this tested with the Flatpak (sandboxed) version of Snapshot? Or did you run it without sandbox somehow?
The reason I ask is that the unsandboxed version may use an accelerated jpeg encoder - which maybe breaks the rotation.
All my tests are with locally-compiled packages of the latest releases / alphas of gtk4.0, libadwaita and gnome-snapshot. libcamera and pipewire are used from the alpine repo since their distro packages are already up to date with the latest releases.
is essentially a workaround for performance problems like 4. as well as a design issue - we might want to come up and implement a mode selection.
custom user scripts are something that I don't think has a place in Snapshot, but fortunately it would be pretty easy to build an app that supports this, using Snapshots aperture library (just like a bunch of other apps already do, like Authenticator, Warp, Decoder).
there are a bunch of low-hanging fruits that should allow to get much better here. Right now we have about 5 or 6 copies until the frame gets on the screen, blits in GTK and the compositor counted in - getting that down to 1 copy is what we possibly can archive. GLES based debayering in libcamera would be great as well.
I guess after that there'll be additional work needed to hook it up to the PinePhone's ISP, like that branch is doing for the Pro's ISP?
Note that AFAIK the way autofocus works in Megapixels is to just load the AF firmware into the driver and let the camera itself do the AF, rather than the software controlling the lens itself.
Yeah, from what I understand in libcamera we'll have the choice of using the native or "software" AF - and either way we'll need to do some more plumbing for camera controls in Pipewire.
Unsurprisingly it doesn't work on scorpio, at least not OOTB. I guess libcamera support is necessary.
The libcamera situation on scorpio could be summarized in two points:
The current register table-based sensor driver lacks some controls that libcamera requires. I won't be adding these controls or otherwise do anything with the current driver because
I got the CCS driver to work near-flawlessly, and I'm planning to migrate over to it since it's a much cleaner solution. The CCS driver has all the controls libcamera needs, except it exposes the sensor as 3 separate components (pixel array, binner, scaler) each with its own set of controls. This is more accurate to how the sensor works, but as of now libcamera can't handle a sensor consisting of 3 V4L2 subdevices.
If you've got a device working with the CCS driver - that's very interesting to the libcamera project. I haven't even seen a device use it yet! We can definitely add support for that to libcamera.
Regarding the PinePhone Pro, I think the most important issues remaining are:
Taking a picture crashes Snapshot. The reason is that it implicitly uses hw-accelerated jpec encoding via v4l2jpecenc and apparently the kernel driver is buggy. This can be worked around by e.g. creating /etc/profile.d/gstreamer.sh with the content export GST_PLUGIN_FEATURE_RANK=v4l2jpegenc:0, forcing the use of the software encoder. Not sure where to add this workaround, but I guess the kernel package would be a suitable place?
The back camera breaks after suspend, apparently fixed in this commit. As that kernel version is likely still a while out, it might make sense to backport the patch. (or just update to 6.9 now?)
With those issue fixed I think we should ship Snapshot by default on that device, given that Megapixels is not installed any more and crashes on startup.