DietPi-Config | RPi: Add modern RPi camera module support

[isarrider]

Hi,

just as a hint for other users, in my Octoprint as docker container setup, the webcam only works, if I include camera_auto_detect=1 in the config.txt on my Pi4

Maybe put it right above the start_x=1

BR, Alex

[MichaIng]

Many thanks for your report.

Indeed I recognised this. Basically start_x=1 is to enable the legacy firmware based camera features, when the legacy non-GL display driver or fake KMS is used. When full KMS is used camera_auto_detect=1 is the correct way to enable the camera module, making use of generic libcamera and V4L2 libraries, as far as I understand. start_x is then not required.

We can toggle the correct setting based on display driver:

• When enabling the camera module option, setting camera_auto_detect=1 or start_x=1 based on whether full KMS is used or not.
• When switching between fake KMS/full KMS/legacy and the camera module is enabled, switch between camera_auto_detect=1 and start_x=1 accordingly.

Just to be sure, can you verify that you have full KMS enabled?

grep 'vc4-.*-v3d' /boot/config.txt

[isarrider]

it seems my statement wasnt right afterall... after a reboot - the cam only works with start_x=1, I had to set #camera_auto_detect=1... But now the picture also became messed up...

[isarrider]

Ill investigate further... (also some peops think its related to bullseye: https://issueexplorer.com/issue/raspberrypi/linux/4697)

[isarrider]

ok, it seems my env variables didnt work out... situation now is: start_x=1

camera_auto_detect=1

(and docker run -d --restart -v octoprint:/octoprint --device /dev/ttyUSB0:/dev/ttyUSB0 --device /dev/video0:/dev/video0 -e ENABLE_MJPG_STREAMER=true -e "MJPG_STREAMER_INPUT=-r 800x600 -f 15 -y" -p 80:80 --name octoprint octoprint/octoprint) works now... sry for the confusion...

[MichaIng]

Can you check with the suggested command whether KMS is enabled or not? As said, as far as I understood, camera_auto_detect=1 works only with full KMS enabled, while start_x=1 works only with legacy or fake KMS driver.

[isarrider]

grep 'vc4-.*-v3d' /boot/config.txt throw nth out...

[MichaIng]

Okay, then you do not have KMS enabled and it makes sense that start_x=1 must be used instead of camera_auto_detect=1. You could test to switch:

sed -i 's/^[[:blank:]]*start_x=.*$/#start_x=0/' /boot/config.txt
G_CONFIG_INJECT 'dtoverlay=vc4-f?kms-v3d' 'dtoverlay=vc4-kms-v3d' /boot/config.txt
G_CONFIG_INJECT 'camera_auto_detect=' 'camera_auto_detect=1' /boot/config.txt
reboot

[isarrider]

doesnt boot anymore after these 4 cmds...

[MichaIng]

?? Are you sure that it is not just the screen which stays blank for a while? It is basically impossible to break boot with those changes, even invalid entries are gracefully ignored. But when during boot it is switched from framebuffer output to KMS, the screen blanks for a while (some seconds). We also got reports where the monitor stood in energy savings mode for some reason. So check SSH.

[isarrider]

I am using it always per ssh...

[isarrider]

changed it back > boots

[MichaIng]

Mysterious, it is actually impossible that those commands have this effect, even with typos inside. Only if somehow KMS triggers a bit of additional power usage at some boot stage or so.

Ah, if I remember correctly in the one case where the screen stood blank, commenting the gpu_mem_* settings solved it, hence reducing GPU memory back to default. The KMS driver does not use this anymore but the system memory via CMA instead. Not sure how/why increased GPU memory causes this, as long as there is sufficient system memory, but probably it as well has a side effect in your case. Puhh, this makes our implementation more complicated as I'm not sure whether with KMS there is still a reason/use case where increased GPU memory may be needed 🤔.

[isarrider]

I have set it to 128MB (the GPU mem) tmr I can do additional tests...

[MichaIng]

Jep, with start_x=1, 128 MiB is added automatically, also required to cover full legacy camera support, but the new implementation doesn't require it. Since I have no other explanation why the system wouldn't boot, when you find time, would be worth a test.

[isarrider]

ok, it seems it is somehow related with the Pi4 being powered by the 3D-Printer... When I power it with an external Powerplug, it comes up... Ill dig into it a bit more...

[isarrider]

Ok, it cannot load the webcam with dtoverlay=vc4-kms-v3d Ill go back to my old "legacy" setup...

[isarrider]

https://forums.raspberrypi.com/viewtopic.php?p=1958297

[isarrider]

as info...

[isarrider]

Ill test on the weekend a bit more...

[isarrider]

https://forums.raspberrypi.com/viewtopic.php?t=319596

[MichaIng]

Thanks. Looks like the new camera stack is not yet 100% stable/reliable. Since there is also some other work to do regarding KMS stack and GPU memory, I deferred this to next DietPi version.

To avoid all the cross-dependencies between those settings, including also HDMI audio, GPU memory etc, I'm even considering to remove legacy graphics stack handling in DietPi completely and ship all images with full KMS enabled by default. But since there are still some issues, probably not with next version yet.

[isarrider]

that sounds intresting... if there is a "beta", lmk... ;)

[isarrider]

as a funfact, it is only that my Pi4 doesnt boot when it is powered over GPIO, the other Pis come up fine with dtoverlay=vc4-kms-v3d... I will try to research the web a bit more... (so it is a hassle to try if the cam would work") Maybe I can find more in the coming days...

[isarrider]

ok, with dtoverlay=vc4-kms-v3d and camera_auto_detect=1, I can see my cam. (via v4l2-ctl --list-devices it shows up)... that still leaves the question why it doesnt boot when powered via the GPIO Pins (and why I cannot see it in my octprint container)

Judging by the 2nd issue and how many peops have problems with it on bullseye, I will suspend this investigating and resume it at some point later this year... Thx @MichaIng - it is clear now dietPi is not to blame ;)

[MichaIng]

Hmm, I never tried to power an RPi via GPIO pins, but I know that it should generally work, e.g. for using the power USB socket in gadget mode instead. Power source voltage and current are of course something to verify whether sufficient and stable enough (voltage stays tight enough in borders). Generally on that topic: https://forums.raspberrypi.com/viewtopic.php?t=248280

[isarrider]

hehe, clear, my DCDC is supposed to handle 3A (and I doubt that only having dtoverlay=vc4-kms-v3d in the cmd causes powerspikes just while booting bigger than loading all cores when booted up) - anyway I will investigate further the latest when Octoprint finally doesnt use mjpg anymore and the h264 HW encoder....

[MichaIng]

hehe, clear, my DCDC is supposed to handle 3A (and I doubt that only having dtoverlay=vc4-kms-v3d in the cmd causes powerspikes just while booting bigger than loading all cores when booted up)

Should be fine then. I also cannot imagine KMS being the issue. Btw, how do you recognise that it doesn't boot? I remember some cases where KMS left the screen blank while the system does actually boot. What definitely happens is that the screen turns off for a second or so before popping up again, like if it switches from one to the other mode.

[isarrider]

all my Pis (is this the plural? ;)) run headless, so I ssh in... also I can see from the LEDs what looks like a bootloop and not a regular system up...

[MichaIng]

Not sure then. Probably a screen or better a serial/UART console could help to debug.

[isarrider]

Ill try to see if I can get sth useful with libcamera-vid... (Powered via USB-C and not in a docker container) If yes, what I guess, it isnt related to dietPi and we can close this...

[isarrider]

played around a bit last night but no real success... guess have to wait for maturing...

[isarrider]

ok, I will have more time in the coming weeks... How far has the plan matured to throw out the legacy stuff? Then I would do tests...

[MichaIng]

Since there are at least two software titles requiring legacy camera support, I think for now we should add a switch only. E.g. change the "On/Off" toggle into a "Modern/Legacy/Off" menu.

[isarrider]

ok like that (what are the two btw?)

[isarrider]

are there still 2 sw titles with legacy cam support?

[MichaIng]

RPi Cam Control and motionEye, probably mjpg-streamer, not entirely sure. Generally, with modern camera stack enabled, /dev/videoX devices are available, but at least from motionEye I know that there are a large number of those, and selecting any one as video input for motion, like one would do with a regular V4L2 camera (e.g. USB camer) does not work. There were many reports like this at motionEye repo, and the only solution was to revert to legacy camera stack, use a 32-bit system and MMAL.