Hi, I tried the V4L2 driver with Buster which worked OK on a Pi4 4 GB then I tested Bullseye with the legacy mode and the same V4L2 driver ( veyecam2m ver 5.10.63) and that worked OK too.
I was previously testing with a Pi 3A which I would like to work but that does seem to have a problem with the v4L2 driver with both OS's.

I have the IMX327E boards. I am currently trying with bullseye 5.10.63.
I installed the veyecam2m driver and updated the raspi-config to be able to select legacy support but I cannot get motioneye to work nor can I get the gstreamer tests on your readme on github for the v4l2. I see that the readme is out of date compared with the wiki but I still cannot get gstreamer to work.
This all seems in order....

pi@raspberrypi:~ $ dmesg |grep veye
[ 11.775403] veyecam2m 10-003b: camera id is veyecam2m
[ 11.778121] veyecam2m 10-003b: sensor is IMX327
[ 11.778144] veyecam2m 10-003b: board type is TWO board
[ 11.779786] veyecam2m 10-003b: veyecam2m camera probed

@raspberrypi:~ $ ls /dev/video0
/dev/video0

pi@raspberrypi:~ $ v4l2-ctl --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture

    [0]: 'UYVY' (UYVY 4:2:2)
            Size: Discrete 1920x1080

But gstreamer gives:-

pi@raspberrypi:~ $ gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video0 ! 'video/x-raw, format=(string)UYVY, width=1920,height=1080' ! jpegenc ! filesink location=test_image.jpg
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting Pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory.
Additional debug info:
../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Buffer pool activation failed
Execution ended after 0:00:00.004531494
Setting pipeline to NULL ...
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Freeing pipeline ...

I emailed 'xumm' and was told
"Please use veyecam2m.ko, this module support all 2M pixel VEYE-MIPI-* camera modules."
So I believe the installation line:-
sudo ./install_driver.sh [camera module]

should use a [module name] of veyecam2m, which seems to install but as yet I don't have a fully working system motioneye or allsky system using it. I should find out soon...

Does the IMX327E camera work on Bullseye with libcamera i.e. not in legacy mode? If not, are you working on supporting it?

The two 5.10.63 releases are missing the imx327 versions of the driver, would it be possible to release these files as well?

With this fix it seems more reliable but it did crash again last night leaving a veye_raspistill Zombie. Short stack trace:-

Apr 11 23:31:21 allsky kernel: [22053.109872] WARNING: CPU: 3 PID: 20358 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xec/0x128
Apr 11 23:31:21 allsky kernel: [22053.109884] Firmware transaction timeout
Apr 11 23:31:21 allsky kernel: [22053.109895] Modules linked in: rpcsec_gss_krb5 8021q garp stp llc spidev brcmfmac brcmutil sha256_generic i2c_mux_pinctrl i2c_mux raspberrypi_hwmon cfg80211 rfkill bcm2835_codec(C) v4l2_mem2mem bcm2835_v4l2(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) videobuf2_vmalloc snd_bcm2835(C) videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common snd_pcm snd_timer i2c_bcm2835 snd spi_bcm2835 videodev mc vc_sm_cma(C) uio_pdrv_genirq uio fixed i2c_dev ip_tables x_tables ipv6
Apr 11 23:31:21 allsky kernel: [22053.110362] CPU: 3 PID: 20358 Comm: kworker/3:0 Tainted: G C 5.10.17-v7+ #1403
Apr 11 23:31:21 allsky kernel: [22053.110369] Hardware name: BCM2835
Apr 11 23:31:21 allsky kernel: [22053.110386] Workqueue: events dbs_work_handler

camera_buffer_callback() should always post via vcos_semaphore_post() even if there is a disk write error or disk full, so in the code where "complete = 1" is commented out it shouldn't be.

Hi, Last night I had a failure just using the 32Gbyte SD card and there is 15G available I got this syslog trace.
Is there a way of sharing the whole file with you as it gets flagged as spam if I put much here?
Here is a short extract :

Apr 7 04:15:58 allsky allsky.sh[661]: mmal: Splitter has 4 output port,you could use num 2,3 for extend
Apr 7 04:15:59 allsky allsky.sh[661]: Opening output file image.jpg
Apr 7 04:15:59 allsky allsky.sh[661]: mmal: camera_buffer_callback data len is 931322 file handle is ba5718
Apr 7 04:15:59 allsky allsky.sh[661]: mmal: camera_buffer_callback data len is 931074 file handle is ba5718
Apr 7 04:15:59 allsky allsky.sh[661]: mmal: Unable to write buffer to file - aborting 0 vs 931074
Apr 7 04:16:01 allsky kernel: [51999.788089] ------------[ cut here ]------------
Apr 7 04:16:01 allsky kernel: [51999.788135] WARNING: CPU: 2 PID: 8580 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xec/0x128
Apr 7 04:16:01 allsky kernel: [51999.788147] Firmware transaction timeout
Apr 7 04:16:01 allsky kernel: [51999.788158] Modules linked in: cmac bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc spidev brcmfmac brcmutil raspberrypi_hwmon sha256_generic i2c_mux_pinctrl i2c_mux cfg80211 bcm2835_codec(C) rfkill v4l2_mem2mem bcm2835_v4l2(C) videobuf2_vmalloc bcm2835_isp(C) bcm2835_mmal_vchiq(C) videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 snd_bcm2835(C) videobuf2_common snd_pcm snd_timer videodev snd mc vc_sm_cma(C) spi_bcm2835 i2c_bcm2835 uio_pdrv_genirq uio fixed i2c_dev ip_tables x_tables ipv6

I wonder if this could be anything to do with a file write error not be handled properly? In my ideal configuration the image file is would be written directly to a mounted NFS drive but currently it is written to SD card first and then copied across, so I can't see why this would affect the function of the veye_raspistill command completion as this appears to lock on an 'futex'.
The system seems to be more reliable if no NFS drive is mapped and copied to but I have insufficient evidence to be sure.
I have also experimented using a timelapse option for veye_rasptistill but this stopped after 9999 files had been written (even using %08 in the filename) but I could be wanting to write 30K to 40K files overnight.
I was expecting at least a 64K file limit and could have understood a 32K limit.
I need to try this again for repeatability and try with the official raspberry camera too.

@veye_xumm
It may be worse on the latest updated Buster release but I am currently working from the December 2020 release and it still happens.

If it helps my code is at
https://github.com/bleara/allsky
This is still in development so some of the configuration is still to be fully done but it might help you with your replication of the problem, although it might also be a distraction. It needs the camera set in config.sh as CAMERA="RPi_VEYE" as auto will not work.
Some nights it will only run for an hour or two others like last night it ran for 12 hours.
I am now using a timeout like "timeout 10s veye_raspistill ...." but last night that hung too.