Verify picam works on pisentry
|Status:||In Progress||Start date:||26 Jul 2021|
|Category:||09 - Testing|
|Target version:||2.0 - Harkonnen|
|Severity:||01 - Critical|
Now that pisentry works with TFTs, test picam on the TFT. It should be used for positioning the camera.
Also re-verify webcam is working on pisentry.
RM #852: Add -S to cross build to allow for pisentry build, which uses new -s cli option to disable vt switching (TFTs don't need it). Fix touch screen identification so picam can tell when it's on a TFT too.
#1 Updated by Hammel about 1 month ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
omxplayer won't play to /dev/fb1 where the TFT is located. Apparently the fbcp program can be run as a daemon to copy the default display. That display is not actually /dev/fd0 but rather an OpenMax display. The fbcp program is pretty small and easy to run but it's going to chew up resources by constantly trying to do the copy. It's also not clear if the xterm hack used on HDMI will work as designed with fbcp.
If fbcp does work it may need to be started before omxplayer and then stopped afterward.
An improved (possibly more efficient) version is raspi2fb.
And another version that is based on the original so won't be as efficient but might reduce tearing.
More discussion on these is here.
#2 Updated by Hammel about 1 month ago
The fbcp source repos are built with CMake, which sucks. There is very little code there and switching to autoconf or even just plain old GNU Make should be easy. So I'm going to fork raspi2fb and remake it's build system so it's easier to fit within the structures of PiBox packages.
#3 Updated by Hammel about 1 month ago
I created a raspi2fb package and it builds and runs okay. Initial tests fail - it's not copying to /dev/fb1, not to mention that touchscreen and keyboard input are lost too.
An alternative is to run either mplayer or vlc. Both are available as Buildroot packages (saving me the trouble of building them manually). This is how you run vlc:
cvlc v4l2:// :v4l-vdev="/dev/video0" --fullscreen
mplayer tv:// -tv driver=v4l2:device=/dev/video0:width=1280:height=720:fps=30:outfmt=yuy2 -fs
However, mplayer isn't in buildroot. But mpv is.
mpv -fs /dev/video0
Both mplayer and vlc use MPRIS for the dbus interface. vlc enables this with --control dbus. So I should be able to do something like I do with omxplayer.
#4 Updated by Hammel about 1 month ago
- % Done changed from 10 to 60
None of the vlc/mpv options worked and the build for them mucked up my rootfs build so I had to rebuild everything overnight last night.
Today I found that I was still running with piboxd incorrectly because the fix I had for it (to use -s instead of -S) was propagated to the metabuild. I've fixed that now.
So I tried running picam with both fbcp and raspi2fb and both worked! The trick is to start picam first and then, a few seconds later, start raspi2fb. If you start raspi2fb first it doesn't seem to work. Not sure why but it doesn't matter because I just need raspi2fb for the video playback.
The next problem was that once I started picam I lost keyboard input so couldn't kill it off. This is due to the vt switch required on the hdmi display. Disabling that makes the keyboard work again.
The last issue is that the touchscreen support is not working. I should be able to touch the screen to exit picam but that doesn't seem to be working.
#5 Updated by Hammel about 1 month ago
- % Done changed from 60 to 70
Okay, this is all fixed now and I can view the webcam on the TFT display if I run it manually.
To get it to work from the UI I need to integrate the use of raspi2fb. That means launching a separate program after the webcam player is started. Not sure how I should do that yet, but it's details.
The important bit is that this actually works now!
One other thing: I need to verify that network setup still works and that the webcam can be viewed by going to the node's piboxwww URL, re: <ip>:2001.
Once picam is working via the UI I need to make sure that I'm not leaving any extraneous processes around - either the mjpg-streamer process or picam or raspi2fb. And I need to make sure that both picam and piboxwww can tell if mjpg-streamer is running - or maybe just have piboxd ignore requests if the mjpg-streamer is already running. That should be tracked in a different issue, however.