MichaIng

A first generic container image is up: https://dietpi.com/downloads/images/DietPi_Container-x86_64-Bullseye.7z But it's with regular `/etc/fstab` and without network stack, hence wouldn't work as LXC container, as of above topics. It however works...

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...

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...

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: ```sh sed -i 's/^[[:blank:]]*start_x=.*$/#start_x=0/' /boot/config.txt...

?? 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...

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...

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...

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...

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....

> 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...