Just for your info it is very sluggish and freezing on 4b 1gb, while it works well on 8gb version.

I run QT Creator on Raspberry Pi 4B 4GB and it works fine.

Finally I have managed to make some progress. Method detectCameras() no longer crashes. And driver starts in EKOS (see attached image).

More here: github.com/sajmons/indi-3rdparty/commit/...7f51c85f3f06789f2c4e.

OUTTA, Jasem, what would be next step? Probably fill in more information about camera capabilities, so that more buttons in EKOS gets enabled?

I wonder if we'd be better off creating a static CameraManager instead of this create/destroy dance. We'd probably have to pull more bits of the libcamera-apps code in rather than linking to it, but that might not be such a bad thing sone those seem to be demos that might be unstable and/or depend on Raspberry Pi specific components. I'll start looking into what that would look like.

Awesome progress Simon! Yes next step would be to make Image Info field editable unless we can query such information from libcamera itself. An alternative is like the V42L driver, we create a maintain a table of known cameras with their resolution and pixel information saved.

Yeah, I totally agree with you Tyler. As it seams, cameraManager needs to be called everytime you want to access to camera object.

It would be a lot easier to find camera and create pointer to camera once. Probably in connect() method?

Then keep cameraManager opened until disconnect() is called. Inside disconect() we release camera and stop camera manager.

What do you think Tyler?

I'm still learning, C++ is not my expertise.

Even with this fix, it still crashes for me when Connecting calling
Also, I get a ton of compile warnings:

Hello, Let me put my two cents as well here
First, I have solved stability issues with 1GB rpi, i added ssd and created SWAP partition on it.

Simon, you are now way ahead of me! I am still having trouble running anything, but due to your fix on startup, I have detected that my version of Kstars is faulty. Kstars was installed directly from raspberryPi repo, and it is missing some icons, that should give me some idea.

When I connect from remote Kstars located on Astroberry I can now connect to Libcamera driver, not able to take capture or stream but I do connect.

In regards with Tylers comment, I completely agree that we should extract stuff from libcamera-apps, if possible completely remove dependency to libcamera-apps (not libcamera it self, I believe that is not possible), but maybe we should focus on that after we enable basic stuff to work.

Jason, I would prefer not to keep table as that is harder to maintain, but it might be necessary, unless we can get all the stuff we need from libcamera. We can get a some details from libcamera: supported resolutions, supported binnings, supported max FPS, is frame packed or unpacked, and raw coding of frame. am not sure if we can get pixel size, and that could be a problem.

Anjo I had similar problems when compiling. I only solved it by manually changing file mentioned on end of this thread:
www.indilib.org/forum/development/12628-...ambiguous.html#88125

That's exactly what I was thinking, maybe with a wrapper to isolate the libcamera bits in a single place to keep it easy to make adjustments as they make API changes.

If you experiance ERROR DeviceEnumerator device_enumerator.cpp:165 Removing media device /dev/media1 while still in use
It help if you just kill indiserver with this command:

Yeeeeeej, rebooting isn't necessary any more! This is such a time saver!

Yes ANJO indeed code inside Connect() method was causing EKOS troubles.
When I comented it completely out, EKOS starts and all buttons are active (see attached GIF).
Of course it crashes when I press image capture button, but that's OK

See here for comented part of code: github.com/sajmons/indi-3rdparty/commit/...75e5c36cabf5fc9788ba

Next task is to figure out how to get that button to work! I have a feeling that it ain't gonna be easy!

You can actually enable that code in connect again and just comment out the m_StillApp->Parse() whicn is what causes the crash.

The bad new is that it still crashes in workerExposure when touching the m_StillApp object. a) it was never opened and b) if you try to open it, it says it' can't be opened... if you don't open if, you crash in ConfigureStill