so I recently switched to Ubuntu (PopOS to be exact) and while the camera worked at least most of the time before on Manjaro, now all I get is a black screen.
With guvcview and others, the camera works fine, just fine.
Here’s the console output:
“SMI: SMI” “/dev/video0”
res: 320 x 240
res: 640 x 480
res: 1024 x 768
res: 1280 x 720
res: 1280 x 960
res: 1600 x 1200
res: 2048 x 1536
res: 2592 x 1944
default: -1 x -1
Setting res: 2592 x 1944
CameraBin error: “Allocation failed”
CameraBin error: “Internal data stream error.”
“SMI: SMI” “/dev/video0”
“CameraBin”? Is this not using v4l2 internally?
Also, it would be really good to control the camera settings, such as brightness, gamma and others, as well as manually selecting the res, which can provide a much smoother experience on some cameras.
I believe LightBurn uses QT libraries for managing the camera. QT in turn I believe does use v4l2 either directly or indirectly through gstreamer.
Not certain but my hunch is that this is likely related to a gstreamer library incompatibility.
What version of PopOS are you running? If you’re running 22.04 that’s based on Ubuntu 22.04 which is newer than the version of Ubuntu (20.04) used to build LightBurn. If you’re not married to 22.04 you may want to try 20.04 to see if that works with the camera. This may also give a clue as to the root cause issue.
Not certain but I think this is an inherited dependency from the version of QT5 that LightBurn is built on.
Indeed. From previous posts I believe there are library dependencies that don’t have native arm support which is one of the complications involved. In reality, the only practical implementations for a native port at this time would be arm Mac and to a far lesser degree Pi on Linux.
I think I’ve read that as well at some point, however I haven’t seen any mentions on what libraries exactly? “About” mentions only OpenCV and Potrace, both of which are open source, and should be no problem. Maybe something proprietary? If so, then one could probably request arm64 compatible binaries?
There are also multiple mentions of Linux users being by far the minority, and for that reason the issues are pushed back (indefinitely?).
I think this logic ignores the chicken or egg dilemma - if there was an option to run it on a Pi, I imagine a lot of people would.
I suspect this is more to do with Linux not being the platform to force a transition away from the current version of QT. All platforms will benefit once QT does get updated.
I don’t think LightBurn has any interest in creating a new platform market. They’re not Valve. They seem more interested in trying to address the available market which happily does include a strong Linux minority.
While it’s not entirely fair to gauge this on a janky, not streamlined method of using emulation to run on Pi, but I’ve seen basically no interest in even attempting the method outlined in the post, neither from casual users or enthusiasts. This is in contrast to many earlier stated inquiries about doing this. Again, that isn’t to say there isn’t a market for a simple well supported version of this but the size of the market clamoring for this may not be as large as intuited.
I agree. Most current users on the forum already went through the hurdle of setting up a PC for Lightburn, so there definitely will be limited resonance. The interested (new) user will probably try it or look it up, the odd one will post here and ask, see that there’s no reasonable way at the moment, and then continue setting up whatever is decently supported, because there’s hardly an alternative anyway.
It all boils down to “would’ve been nice if I could’ve kept using my Pi”.
And I can see where you’re coming from. Implementing features users are interested in is more “attractive” and can take precedence, but most of those issues seem to come from missing dependency management; they just seem to surface primarily on Linux. And those issues come back with a vengeance only some time later
Anyway - I have installed the old ssl library and got the updater to work.
Installing gstreamer and various other libs seemed to make no difference however, so the CameraBin error remains.
By the way, it’s not how I would like things. I’m just trying to understand the situation. I’d love it if Linux were front and center and I’d be frankly fine with it if it was even the only platform. However, that’s not the situation we’re in and I understand the developers’ priorities.
Hmm… What model of camera do you have? I don’t know if I’ll have the setup to try to reproduce this but I can see.
It’s basically some random 160° widescreen cam from AliExpress, reported as “SMI” - but every other cam won’t work either, like the MacBook cam that’s in there as well. And both work with guvcview.
I’ve changed to MacOS for now.