Back/World camera working after suspend

[DrYak]

Some people might be affected by some driver bug where the camera:

• does works right after boot of the PinePhone Pro.
  
• But after suspend, the camera stops working.
  

e.g.: that's the case when using application Shutter on SailfishOS.

The following trick forces reinitialising the hardware (as if the kernel is populating from device tree during a boot):

Code:

echo ff920000.isp1 | sudo tee /sys/bus/platform/drivers/rkisp1/{unbind,bind}

[u-kidjp]

Some people might be affected by some driver bug where the camera:

• does works right after boot of the PinePhone Pro.
  
• But after suspend, the camera stops working.
  

e.g.: that's the case when using application Shutter on SailfishOS.

The following trick forces reinitialising the hardware (as if the kernel is populating from device tree during a boot):

Code:

echo ff920000.isp1 | sudo tee /sys/bus/platform/drivers/rkisp1/{unbind,bind}

Thank you.
I added script
/lib/systemd/system-sleep/90-restore-cam.sleep
on mobian. It seems to work well.

Code:

#!/bin/sh

PATH=/sbin:/usr/sbin:/bin:/usr/bin

case "$1" in
    pre)
        #code execution BEFORE sleeping/hibernating/suspending
    ;;
    post)
        #code execution AFTER resuming
        echo ff920000.isp1 > /sys/bus/platform/drivers/rkisp1/unbind
        echo ff920000.isp1 > /sys/bus/platform/drivers/rkisp1/bind
    ;;
esac

exit 0

[DrYak]

I added script
/lib/systemd/system-sleep/90-restore-cam.sleep

That's a very cool solution! ?


(Sadly in the case of SailfishOS that doesn't work. Apparently the solution for suspend used there doesn't run those scripts ).

---

@megous : Is there a way that you could do this in a "cannocial" way in the driver code ?

[Jite]

I added script
/lib/systemd/system-sleep/90-restore-cam.sleep

That's a very cool solution! ?


(Sadly in the case of SailfishOS that doesn't work. Apparently the solution for suspend used there doesn't run those scripts ).

---

@megous : Is there a way that you could do this in a "cannocial" way in the driver code ?

This is obviously really cool. Has anyone got this working on pmos or alarm?

[Kevin Kofler]

I have not tested it (my original/non-Pro PinePhone does not need it), but I would expect this to work as is on Arch Linux ARM (DanctNIX, but also derivatives like Manjaro ARM) as is, because they also use systemd. On postmarketOS, only if you use a systemd-based version (latest edge, and not installed from the SXMO image, or if you use manual pmbootstrap, only if you keep the systemd option enabled). Otherwise, you need to figure out how to do the same with OpenRC.

[Jite]

I have not tested it (my original/non-Pro PinePhone does not need it), but I would expect this to work as is on Arch Linux ARM (DanctNIX, but also derivatives like Manjaro ARM) as is, because they also use systemd. On postmarketOS, only if you use a systemd-based version (latest edge, and not installed from the SXMO image, or if you use manual pmbootstrap, only if you keep the systemd option enabled). Otherwise, you need to figure out how to do the same with OpenRC.

Hmm. Tried this on arch linux arm and it seemed to crash the system needing a restart. Tried this on a few occasions with the same result. The good news is that it definitely does something. Not quite certain why this command would not work on postmarket os as I am trying to figure out which part of the command is systemd specific as the path to the driver is the same on pmos...

[Jite]

I have not tested it (my original/non-Pro PinePhone does not need it), but I would expect this to work as is on Arch Linux ARM (DanctNIX, but also derivatives like Manjaro ARM) as is, because they also use systemd. On postmarketOS, only if you use a systemd-based version (latest edge, and not installed from the SXMO image, or if you use manual pmbootstrap, only if you keep the systemd option enabled). Otherwise, you need to figure out how to do the same with OpenRC.

Hmm. Tried this on arch linux arm and it seemed to crash the system needing a restart. Tried this on a few occasions with the same result. The good news is that it definitely does something. Not quite certain why this command would not work on postmarket os as I am trying to figure out which part of the command is systemd specific as the path to the driver is the same on pmos...

Having tried this again using snapshot on pmos it does seem to be working...

[gtw]

Hmm. Tried this on arch linux arm and it seemed to crash the system needing a restart. Tried this on a few occasions with the same result. The good news is that it definitely does something. Not quite certain why this command would not work on postmarket os as I am trying to figure out which part of the command is systemd specific as the path to the driver is the same on pmos...

Having tried this again using snapshot on pmos it does seem to be working...

Yes, I can reproduce your results: the rkisp1 unbind works on some systems, but appears to crash the phone on others.  (I suspect it doesn't completely crash the system but does disable the display, making it practically useless.)

As far as I can tell, the crash is caused when the GPU driver is also bound to the shared MIPI D-PHY port (the RK3399 provides three D-PHYs: one TX only which in the PPP is wired to the screen; one TX/RX which in the PPP is used in RX mode for the world-facing camera; and one RX only which in the PPP is the user-facing camera).  Since unbinding the rkisp1 driver also shuts down the PHY, if the kernel thinks the GPU is connected to the PHY then it is disabled as well, killing the screen.

The whole problem can be avoided by telling the GPU driver not to use the camera PHY in the first place (since it doesn't need it), which was implemented in this patch: https://gitlab.com/pine64-org/linux/-/co...3d91766f81

In my testing, the problem does NOT occur under postmarketOS using the pine64 6.6 kernel (which includes the above commit).  It DOES occur using https://codeberg.org/megi/linux/src/tag/...40512-2332 (which for some reason does NOT include the patch); cherry-picking commit 8be04a3e into the latter kernel fixes it.

[Kevin Kofler]

This should be reported to megi. Not sure why he dropped that patch (that he wrote) in the newer branch, might have been by accident.

[biketool]

per Mobian's wiki https://wiki.debian.org/InstallingDebian...ro#Cameras

"The PinePhone Pro has both a front-facing and a rear-facing camera. As of linux 6.12 (Mobian staging), GNOME snapshot is available as a Flatpak and a Debian package. It can take pictures and videos with the front and back cameras."

I keep seeing mention on the forum that there were/are hacks to get it working on Mobian Bookworm(now on Trixie too??), back in 2022 there was even a package maegpixels-ppp(megapixels errors out when it cant find a pinephone conf file) https://redlib.privacyredirect.com/r/pin...pixelsppp/
I am not running staging so with kernel 6.6 I might be waiting for a while as even 'stable' has been sketchy on even stuff like phone usability.  Can anyone report a working cameras AND reliable telephone audio in Trixie staging?  I mostly miss being able to use QR codes so working phone is a priority.

<edit>looked on the https://gitlab.gnome.org/GNOME/snapshot/...HOOTING.md
suad opt install libcamera... Error: Unable to locate package libcamera...
that is going to be a problem I guess
<edit>
Trying one of two flatpaks: page.codeberg.JakobDev.jdFlatpakSnapshot stable
which is a tool to create snapshots of flatpaks...  it is not a camera app
The gnome-snapshot flatpak option fails with no devices just like the one form the mobian repo.